The futility of software project planning

This is a nice little review of Scott Rosenberg's Dreaming in Code. It has a little 'software programmers are bad people' bias, but it's understated.

I had moved from being a journalist and an editor to being the managing editor of a Web site, and we had decided to build, on our own, some software for Salon: a new content management system. But as I tell it in the book, it turns out to be a software disaster, a classic death march situation in which everything went wrong and nothing worked as planned and when we deployed it everything broke.

It's hard to communicate exactly how unpredictable software development is. In many types of projects, once you've finished it, you know how long it would have taken. And that's the sort of process system dynamics talks about well -- particular situations and units of work. But, in software development, there are always many choices, most of which won't work. But, deciding they won't work isn't much easier than actually trying them.

[A]s long as you are not trying to do something new -- if you are doing something that has already been done -- then you have a frame of reference to estimate how long it is going to take, and to guess how many people are going to be required, and so on.

Now, he gets into the 'build vs. buy' argument a little. I used to be pretty categorical about this: building software is always a disaster; if it exists and you can't afford to buy it, you can't afford to do it. Only code when you have to. However, since moving from development to professional services, I've come to understand that buying software is also always a disaster.

[T]he programmer who says, it will be faster for me to write it, rather than to learn it, is usually correct. Except that what he will write, most likely, is something that will work but will not have its rough edges worked out, will not have the benefits of a piece of software that has actually been used for a few years, where the bugs have been found and the users have given feedback and have helped you figure out where the problems are. So what they will often be handing you at the end of that I-can-do-it-faster-myself thing is something that works, but that is kind of a mess in certain ways. Whereas the thing that you were going to pull off the shelf, maybe it will take the programmers a while to learn it, but once they learn it enough to hook it up to this project you are creating, what they are hooking up will probably have a lot fewer problems.

This isn't true. Any software you buy will have had gaps in its testing, probably just right where you want to use it. And, components are often even less well documented than business software, because there's a cultural thread which states that well written code is self-documenting, and documentation is just to please PHBs. This contributes to the bit about writing code being as easy as learning someone else's code, which is truer.

So, I'm thinking maybe I'll read it. I'll get back with you if I do.