Today I became aware of the existence of the Joel Test - a list of questions for assessing the quality of a software development team.
One item on the list puzzled me a little.
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
I was puzzled by number 7: “Do you have a spec?”, but soon found out that it just means: Do you write specs before coding? (Fair enough. I thought “spec” meant something else in this context.)
Writing specs is like flossing: everybody agrees that it’s a good thing, but nobody does it. I’m not sure why this is, but it’s probably because most programmers hate writing documents. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first. I feel that way exactly! I know specs are an important alignment tool when communicating with team members - to keep everyone on the same page, so to speak. But they’re boring to write, and I often have the feeling that the spec writing process takes away an important creative aspect of programming. They tend to make you avoid the unknown and take the safe road. We are often told that programming is a creative endeavor and this is very true.
But why is the creative aspect valuable? One of the things that characterizes other creative fields - such as art or music - is that the artist tends to draw inspiration from the interaction with his or her tools. This inspiration is often a key source of innovation. I bet you Jimi Hendrix didn’t plan on his guitar sounding like that the first time he accidentally cranked up the gain too much and made it feed! But he saw the potential and made rock history with that sound.
I’m certainly no Jimi Hendrix, but I do know this kind of creative process first hand: When I’m working on music, I would, for instance, never dream of having a spec! Instead, what I do is keep my ideas microscopic, then try them out and get something more or less unexpected in return from my machines. Typically, hearing this will spark a new idea in my head, and so in a prolonged, iterative process, I’ll produce a piece of music in close collaboration with my collection of electronic equipment. The result is completely unknown, until it’s suddenly deemed finished.
Of course, that kind of uncompromised creative flow is not viable in a business context - and I’m sure more commercially successful musical artists than me have some way of sneaking a “spec” or a plan into the process in order to keep their productivity high. Inspiration is quite unreliable at times. Any artist will tell you that!
But when it comes to programming, where do we draw the line? How do we keep control of our productivity, while still keeping our process open to the kind of sudden inspirational insights that fuel innovation?