The last Dilbert cartoon

This is a bit of a rant that was brought to mind by a discussion about planning in class. I remembered this cartoon and as I searched for it I realized, this cartoon is probably why I don't read Dilbert anymore. I had known it really irritated me but hadn't realized that it had so alienated me that I have seldom read Dilbert since the strip came out. And whereas before checking out Dilbert had been a daily ritual now it is something I do when I run across a Dilbert cartoon somewhere and have nothing better to do. The cartoon is here.

The point made by Dilbert in the cartoon would be completely true, if they were "measuring and cutting" code. But they aren't working with code and this fundamental error is one of the biggest problems with software development. As software developers, we are measuring and cutting parts of people's lives. Corporate IT developers are measuring and cutting the ability of their fellow employees to do their jobs--I talk to those employees every day. Game developers are measuring and cutting the ability of players to enjoy their games.. That game isn't insignificant--it may well have been what the player was looking forward to all day as they struggled to deal with the frustration evoked by the broken software that their corporate IT developers have provided them to work with. Or the frustration of dealing with the employees who are frustrated by that software. Or in my case, sometimes both!

Of course the question is complicated by the fact that it is more efficient to actually create the code by experimentation and trial and error than by developing a detailed plan that will probably turn out to be wrong. But applying this concept to the entire design and release of software creates broken software. Sure it will eventually get fixed after enough trial and error cycles, but in the meantime the results are terribly frustrating to the end users.

This is exacerbated by a simple fact of life that stretches across domains from economics, to education, to software development: it is always easier to define the cost of solving any problem than it is to define the costs of not solving it. If the problem is environmental, the cost is pollution, disease and species extinction--but these are difficult questions to quantify, and generally hinge on estimates that are sometimes barely more than pure speculation, while the cost of fixing the problem is probably able to be quite accurately defined in billions or trillions of dollars. Similarly in software development, the cost is frustration, alienated customers, and possibly lost productivity which are costs that are nearly impossible to define--especially in advance!--while the cost of fixing any given problem can probably be estimated with a reasonable degree of precision.