Innovation in Software

[Up-front Disclaimer: I didn't do Computer Science at University. I did "Software Engineering". It involved formal methods and quite a lot of Z notation. I have some pretty strong views on Software Engineering as a discipline as a result. Most of my CompSci colleagues generally do not share my beliefs.]

Johannes Ernst posted yesterday a pointer to an article from IEEE Software by Tom DeMarco, pronouncing Software Engineering as “an idea whose time has come and gone”. Tom’s argument can basically be summed up as:

[...] you need to distinguish between two drastically different kinds of projects:

• Project A will eventually cost about a million dollars and produce value of around $1.1 million
• Project B will eventually cost about a million dollars and produce value of more than $50 million

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.”

Frankly, I can’t believe such a narrow and misguided argument has come from the pen of Tom DeMarco.

Imagine if you will the next time I go into tender on a project.

Customer: So how much will this project cost to deliver, and how long will it take?
Me: Well, how much value is it going to add to your business?
Customer: Pardon?
Me: Is it going to add a little bit of value to your business, or a lot?
Customer: A lot, I expect.
Me: In that case, I have no idea. Let’s just roll with it and see where it goes, eh?

I’m not convinced that’ll go down well.

There are a few logical mistakes in Tom’s argument (and I can’t believe I’m having to point them out), that basically means he’s talking a great big pile of crap:

1. We can not assess the true value of software until it is shipped.

   We might be able to sense the potential value, but it’s a guess.

   I have one project on my books now with a mid-sized build budget, potential value in the hundreds of millions. Another project for a smaller build budget with a potential value of £200k-£300k. Another project with a tiny build budget that if it goes viral could be worth billions five years from now.

   Or maybe the project with the tiny build budget sinks, the medium project gets on NASDAQ in 5 years and the biggest project eeks out a living but never goes stellar.

   We simply don’t know. We can’t know. We’re guessing. There are too many variables outside of the software engineering process to be able to assess the potential value accurately.

   In essence, we have to treat all projects as being potentially of very high value, because they all are.

2. Value is potentially nearly unlimited, budgets are not.

   It might be well and dandy to say that it doesn’t matter if the budget might slip because the value is so high, but budgets are fixed.

   Thousands of software builds are being worked on right now where a 5% budget slip is potentially going to kill the project because there just isn’t more money after the budget is gone, and without being feature-complete the software is going to have near-zero value.

   Yes, incremental development is the way to do things, yes we should be able to stop and ship after each day’s work. However to fulfil the project’s objectives (and maximise its potential returnable value), we must aim to get all the features in to the final build within budget.

3. There are other factors beyond budget, schedule and value to control.

   John Glenn once quipped about being sat on the launchpad, “I felt about as good as anybody would, sitting in a capsule on top of a rocket that were both built by the lowest bidder.

   However, whilst budget was important, he shouldn’t have felt in danger: the political ramifications of a death would have meant that the people who built that rocket and capsule were going to make sure he survived.

   And some software systems are the same. What is the “value” of a nuclear power station control system? Or the control systems in a fly-by-wire aircraft? Do we care more about the financial value or the safety value? I would suggest that controlling the build – engineering the build – in these situations is critical because the safety value is very high.

   In fact, it betrays immediately the fallacy of Tom’s that only the marginal projects need tight controlling – if you’re not controlling the processes around a software build that keeps 400 souls alive at 35,000 feet, you really should be in another profession.

There is a lot of cruft in software engineering. Waterfall methodologies are now considered almost laughable. However, it’s a young discipline and we have barely begun to understand the correct way to engineer software.

Agile philosophies are taking over in development shops because it allows for less process, more communication and ultimately better software being produced at the other end.

Behaviour-Driven and Test-Driven Development methodologies are providing useful benefits to our clients in a way we could barely imagine just a couple of years ago. In certain situations, formal methods and algebraic proofs are confirming that software is “correct” and “complete” in such a way we can literally bet our lives on it.

Tom admits himself he’s not on the front-line of software development these days. Perhaps his metric-centric universe is correctly condemned, but most of us aren’t using those methods anyway. We’re looking at perhaps a few numbers instead: test coverage, remaining days in budget/schedule, remaining features to be implemented. We’ve moved on. Perhaps he just doesn’t get what we’re doing in dev shops these days.

And we’re still learning new techniques, new ways of doing less process, more quality software. Software Engineering is definitely not something that has “come and gone”: it has barely got its foot in the door.

Towards the end though, Tom does make one point I can’t agree with more:

Consistency and predictibility are still desirable, but they haven’t ever been the most important things. 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.

This reminded me of a talk given by Ted Nelson at OpenTech 2005 where at one point he almost screamed:

I didn’t get into computers to automate trivial crap! I got into it to change the World!

Didn’t we all? But I think we can do it without having to just free-ride our way along with our fingers crossed, hoping we don’t run out of money.