Starting the conversation on value

From my early days in the field, I have been puzzled by an apparent paradox: T

There are constant  complaints about how immature  and out of control software software development is compared to other engineering fields. Few remember the Nato Conference on the Software Crises in 1968 (I don’t). The conference raised an important issue: With the growing capabilities of computers, we need comparable growth in software development. Apparently, the term software engineering was coined at this conference. That said, the recommendations from the conference were naive (essentially waterfall) and I bet did more harm than good.

The handwringing continued. Twenty-fice years later Scientific American published ‘The Chronic Software Crises’, September, 1994 Meanwhile, there was the infamous, flawed Standish report from 1995. The Standish organization continues this theme with their annual Chaos Reports. (see Scott Ambler’s cogent debunking of the Chaos reports) which reinforce the sense of crises.

Another source of attack on our industry was the claim that IT in the end delivered no real value. IT was just a sort of utility like electricity, essential but only a necessary cost of doing business. IT therefore should managed as a cost center. (See Does IT Matter).

Here is the paradox: Throughout all this naysaying and handwringing, somehow software was able to be the key to huge economic growth. I do not not need to share with this blog’s readers the role software plays in smartphones, apps, hybrid cars,the internet,  the internet of things, cognitive computing, ….

So our industry must be doing something right!

I have been aware of this  paradox for quite a while. One answer I came up with is that software efforts seem to ‘fail’ more often than other engineering efforts because software often takes on more innovative efforts. In fact, if you control for innovation, we do no worse than other engineering disciplines. Look at the cost and schedule overruns for Boston big dig, or the Sydney Opera House. I pick these because the overruns cannot attributed to software. There are lots of other examples including the mechanical design of the Boeing 787, the first composite commercial airliner. If you are doing innovative work, one should expect false starts, and occasional abandoned efforts. However, it is when software takes on the risk to develop innovation that it has the opportunity to deliver the most value. High risk, high reward.

It also should be noted that we have made good progress in learning how to organize and manage software efforts over the last decades, especially with the adoption of agile and lean methods.  Scott’s article captures this well.

So, even though there is not (nor probably never was) a software crises, our industry does have a value problem. It is not that we don’t deliver value, we do. It is that we do not measure the value we deliver. This  was a point in a recent CACM article. I have personally seen a growth in interest of software shops to start managing not only the cost, but the value of what they are delivering.

The reason we do not often measure value is that it is hard to do. However, it is not impossible.

I will continue this discussion in the next posting.