Is Software Engineering Dead? (Process, not Construction)

Tom DeMarco, author of the seminal book Peopleware has written a short, interesting article Software Engineering, An Idea Whose Time has Come and Gone?

DeMarco’s article is really around engineering as it refers to controlling the process of creating software, not the actual software construction itself. The article’s short and doesn’t start any in-depth discussion, but the general point is awfully good: working too hard to control the process of software construction is a bad thing. A great quote from the article:

For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

We can’t use this as an excuse for being sloppy with our clients’ time or money, be those clients internal or external. That said, the points DeMarco makes line right up with my own beliefs:

• As an industry, we suck at estimation. Badly. The problems we solve are similar, but nearly always different from each other.  We make little or no effort to keep a good history of our estimates’ accuracy, nor do we do much to train folks on estimating.
• Because estimation is a time sink, use velocity for projecting project pace and what you can build within the client’s budget. (Get your work item granularity small, though!)
• Value is delivered to clients by creating software, not managing the project. Project management’s critical, but it needs to be a light hand. Oversight and correction versus harsh controls. (That means you’d damned well better spend a lot of time building great teams that are good enough to manage themselves, by the way.)
• Value is delivered to clients by being flexible enough to change what you’re building in order to meet the clients’ changing environment. (Or the clients’ evolving needs as their understanding of the business problem evolves.)

DeMarco’s article is way too short, and I really wish he’d provided more detail on the metrics and measurements he’s decrying – but I think there’s some good conversation starters there.