I had the good fortune to listen to yet another excellent podcast from Dan Benjamin’s 5by5 Studios yesterday - this time the Build and Analyze program Dan co-hosts with Marco Arment (of Instapaper and Tumblr fame).

The show featured a discussion on the typical work cycles of developers and fell into the mistake of re-iterating the stereotype of developers as working great in bursts of time, often late in the night. I’m not going argue much about the time frame - many developers, myself included, do work great at night time.

What I’m going to argue with is with the suggestion that developers write amazingly good code at this time and terrible code at other times (as suggested by Dan¹). Unfortunately I don’t think this is necessarily true - it’s true that developers who are in the zone can churn out a lot of code when they are on a roll, but the quality of that code is not necessarily going to be high (though it could be).

Bugs can occur at any time, and in my opinion, when you’re on a roll there’s just as much chance of introducing bugs. In fact, I’d go so far as to say that when you’re on a roll you could be more prone to introducing bugs, because you’re thinking ahead more than you’re focused on the piece of code you’re writing right now.

Dan and Marco seem to agree that creativity is not something that can be done on demand, but in the end, not all software development is creative (as Marco mentioned in the podcast). Software engineering is like producing music and graphical works - there are flashes of genius which can come at unexpected times. But for the every composer who works to his own schedule, there are many more musicians who work to schedules writing jingles for adverts, music for games, music for film. For every painter, there is a graphic designer churning out a new advert, or graphics for a game, or movie special effects. For every coder who writes a sweet new algorithm for the love of it, there’s another churning out code for cash.

Sometimes software is art, but like any art form it can be degraded to a production line when it needs to be.

“They’re gonna be super-productive. They’re gonna write, y’know, a hundred lines of awesome code in that four hour block of time, they’re gonna fix bugs, they’re gonna get tons of stuff done. But if you try to shoehorn them into doing that work between 9 and noon, let’s say, or 9 and 1, they’re gonna write crap code. It’s gonna have tons of bugs.”