Planning and well-written code

I believe that my statement that “software can’t be planned” is true, because of what most people think planning is about: something that takes place at the beginning of a project, and which produces a plan that should be deviated from as little as possible.

Plans are seen as anything but fluid: they are “nailed down,” “frozen,” formally “agreed upon.” Ambitious projects are very ambitious about planning. Troubled projects are seen as caused by not enough planning, so the suggested remedy is always to do more planning, often coupled with rigorous reporting and tracking of progress.

Once, I got the chance to leaf through a report delivered as the end product of an analysis of a troubled IT department. The analysis was conducted by people from a well-known global management consulting and technology services company, and their solution involved what I gather is their standard recipe: more planning, of course, but also formally signing contracts between the distinct parties of buyer and seller (this company did in-house development).

For all the talk about how planning is something that you do all the time, how plans are useless, but planning indispensable, there is little evidence that this is what planning means to people. So, do we educate people what planning is, or do we switch metaphors?

I think I’m in favor of switching metaphors, because I think there is something about planning, even if you do it all the time, that runs counter to the nature of software development—which is about learning and adaptation.

My post wasn’t about planning, though, but about writing good code. I meant that software can’t be planned as in that you can’t anticipate in what ways the requirements will change in the future, or that you don’t know what you will discover about the problem context.

Mentor Cana said that his personal experience tells him that code can be neat and clean but still not behave as expected. Of course, but this doesn’t rule out the possibility of a correlation between good code and well-functioning applications. I think it’s quite safe to say that an app that without doubt possesses the quality without a name also is well-written—especially if it evolves gracefully, retaining that quality.