There comes a point in every instance of creation when the creator steps back and says, “Done.” But how do you know when a thing is complete? And what happens when you continue past that point?
In this short Tech Talk, Matt, a System Administrator here at Fog Creek, using examples from Computer Science, Finance, and Art, explores different perspectives on this question. It acts as a cautionary tale for anyone involved in software development about the dangers of feature creep and not knowing what done looks like.
About Fog Creek Tech Talks
At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.
Content and Timings
- Computing (0:19)
- Gambling and Finance (0:48)
- Art (1:30)
- Software (3:22)
- Examples of Feature Creep (4:50)
We often lose track of what does done look like and when do we reach it and say, “Enough. Working on this more is not going to help anything.” When you start thinking about this… well, we’ll start with computing.
Computing has a well-defined halting problem. In computability theory, the problem of determining from description of an arbitrary computer program input whether the program will finish running or continue to run forever. This is like basic, way-down, Comp Sci stuff, where does this input associated with this algorithm actually lead and does it meet a condition or does it loop forever. When you start making this more of a human aspect, you wind up with a kind of the mathematical halting problem or the gambler’s dilemma.
Gambling and Finance
The gambler is trying to maximize their profit. They’re a min-maxer; they want to invest the least possible amount and gain the most possible amount. I’ll include finance in here, which is a kind of sophisticated gambling with a little bit more information. The notion is that you have tools, mathematical tools, that you can choose to apply to this problem to figure out what the optimal solution can be. There are tools for this. You can actually sit down with a spreadsheet or some piece of software or a pencil and paper and figure out the proper and optimal solution for this problem. For the creative, you stop when the expression of the idea is complete. When the hell is that?
Well, there are very few mathematical models you can apply to figure out when your watercolor of a beautiful waterfall is finished. There are some boundaries, which are established by the medium. If you’re doing sculpture and you’re chipping away, eventually there’s not going to be any stone to chip away anymore and you are going to have to stop because there’s nothing left, literally. If you are a painter, or a sculptor in clay you can continue to add clay, but eventually gravity is going to take over and say, “all right, you can’t really put that newfangled nose on this statue. It just doesn’t have the support.” There are realities that do apply themselves to certain media. The Statue of Liberty can’t necessarily hold her arms straight out or have forearms because the structural architectural notions of that beautiful thing out in the harbor just doesn’t support that, like Michelangelo up there. “I saw the angel in the marble and carved until I set him free. Every block of stone has a statue inside it and it is the task of the sculptor to discover it.” Michelangelo has this concept of the finished artifact in his head; he’s trying to liberate it from the medium. Ultimately, he knows what he’s looking for. Maybe he doesn’t know specifics, but he’s going to keep trying to pull it out until you wind up with something like this. There’s a more contemporary quote: “Knowing just when to declare a work of art finished is an eternal struggle for many artists. The issue is that if you don’t work on a piece enough, the work can come across as incomplete. On the other hand, overworking a piece can cause the work to appear tired and tedious. The most compelling works of art throughout history are able to establish a strong balance of gesture and spontaneity while simultaneously appearing to be substantial and fully resolved.” Much more fuzzy, no maths going into this. I’m done when I think it’s done.
Then we get to Software. We’ve kind of come full circle. We started with the computing halting problem, we came all the way through art, which is one of the most open, creative processes, and now we’re here at software, which is even more open than art. Yes, the machine implies certain things for you based on the way it acts and the way you can use it, but ultimately you can create literally fantastic worlds inside a machine. When you don’t know when to stop with software, you start suffering what’s called feature creep. Jamie Zawinsky was a programmer for Netscape, and he came up with Zawinsky’s law, which is, “every program attempts to expand until it can read e-mail. Those programs which cannot so expand are replaced by ones which can.” There’s this notion that applications are pushed well beyond their requirements and intentions. You have a program, you’re trying to solve a problem, and then you fall in love with the thing in the process of making it. Then you start thinking, “Well, what else can I add? What else can I do? Where else can I go? Oh, well this function isn’t very good; it doesn’t have that je ne sais quoi I was looking for when I was writing it. I’m going to go back and rewrite it. Oh, there’s a new library; I could re-implement this in another language. I could do this, that and the other.” You can just fall into this hole and get stuck there and never know when done is done, because you’ve lost sight of what you were originally even intending and what the finished state looked like, if you knew what it was in the beginning.
Examples of Feature Creep
This is what feature creep looks like in one image. This is Microsoft Word 2010 with every toolbar enabled; that is all you get to type in. Yes, some people might use these things. Yes, that is an interface to get people to be able to use those things, but, you have long gone past the notion of laying out documents. Here’s another example, and it’s kind of a case study, I think, in not knowing when to stop because you don’t know what it is that you’re trying to come up with.
They had a team, they were in Australia, they were isolated from the rest of the Google environment, and they spent two years working on this thing in isolation, effectively. That’s what it looked like. The paradigm they said they wanted to change was e-mail, and they said they wanted to re-implement e-mail for the 21st century. Nobody knew what Wave was or where it fit in, but it was supposed to… they got so attached to this thing that they kept adding more and more crap to it that it ceased to be e-mail for the 21st century. It turned into this communications hub. They ate so much dog food that it was poisoning them. They spent their entire life in Wave. All of their internal communications, all of their internal documentation, all of the rest of their stuff was all in Wave, and they just expected everybody to do that. This was the central focus of their working life. Whenever they encountered a thing like, “oh, I wish I could send a tweet from within Wave,” or “I wish I could read this RSS feed from within Wave, because I’m always in Wave and I want to be able to do these things,” they kept making more and more and more and more and more complex. Two years later, when they finally crack open the box and join the rest of the world, they have this monstrosity that the only way to use it successfully is to basically have it take over your life and then do all of these things within the context of Wave, which is not what people want.
The question is, ultimately, when do we stop? The answer is when it’s done, which is kind of a cop-out. Because if you don’t figure out what done looks like when you start, you’ll never figure it out along the way. We stop when it’s done. Figuring out what done is is the problem.