Thanks, Tom.
My good friend Steve Colwell sent me a link to a Viewpoints column by Tom DeMarco from the July/August 2009 issue of IEEE Software magazine. Tom DeMarco is of course an industry legend for books such as Peopleware, and is one of the founding fathers of the so-called-discipline of Software Engineering. In his column, Software Engineering: An Idea Whose Time Has Come and Gone?, he basically throws in the towel on much that management has held sacred for the past 40 years.
My Bad
You would think that a guy who wrote a book titled Controlling Software Projects: Management, Measurement, and Estimation would be a hard-core process man, and for years DeMarco has been just that. However, in this column he reflects on the advice he gave back in 1982:
In my reflective mood, I'm wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.
DeMarco then goes on to basically advocate agile processes, while pulling the punch a bit:
So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, "I have a finish date in mind, and I'm not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you've got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go."
This might sound like an agile methods prescription, but I'm too far away today from the actual building of software to recommend at the methods level. Rather, I'm advocating a management approach, one that might well steer the team toward agile methods, at least toward the incremental aspects of the agile school.
An Apology Might Be Nice
The guys who invented Software Engineering around the beginning of my career have been responsible for untold man-years of misery. Travesties such as BDUF, the waterfall method, software metrics, KLOC, etc., have never helped much delivering software on time, but we kept hearing that if we just followed the rules it would all work out just fine.
As far as I can tell, most of what we got from these methodologies was guilt, castigation, and that uneasy sense that everything we were doing was wrong.
Now one of the high priests comes along after all this time and says "Never mind." This leaves me a bit miffed. I wouldn't mind having all those hours of my life back.
Note: the column mentioned here is for sale by the IEEE for $19. I read it from an unobstructed URL which is apparently generated by a "Share this article" link on the site. Since I didn't agree to any licensing arrangement or other restriction on my use of that URL, I'd be happy to send you a copy if you just email me.

