Companies Will Waste $1B This Year on Software Tools

drain

We are collectively flushing the money down the drain.

Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.

Background

Joe Marasco, CEO of Ravenflow, has written an article where he posits that we’re making bad investment decisions when it comes to improving our ability to create successful software. He’s provided data to support is argument.

The Standish Group, in their CHAOS reports has shown dismal software project success rates for the past decade. Digging into the details reveals 40% to 60% of the problems are caused by bad requirements.

Even when we know the problem is with our requirements, we also know that requirements management software will not solve the problem.

Problem Validation

Joe has the brilliant insight to recognize that with three CHAOS reports, we can produce a graph that shows a (possible) linear trend in improvement of a little over 1.5% per year in software project failure rates.

linear failure rate change

With roughly $250 Billion being spent on software projects per year, we are collectively seeing just over $4B in savings per year. Not a very good ROI for our projected $4B investment.

What if the linear assumption is wrong? We know half of the problems come from bad requirements, so there should be a limit to what improved coding efficiency can do. The graph may look more like this.

asymptotic curve approaching 50%

In that case, we’re about to have a negative ROI. Investment keeps going up, and results keep getting smaller.

Lies and Damn Lies

Joe asks “why so little improvement per year?” and raises an interesting point. Perhaps we are solving harder problems and achieving more value with fewer resources as we get more efficient at software. There is no way to reach an empirical conclusion on this, but we think he’s right – we are doing that. But we also think the law of diminishing returns makes the asymptotic curve more likely than the linear.

Engineers and Artisans

One reason that we are not improving faster is that software engineering is not engineering. [I say this as a former registered professional engineer]. Software engineering is requirements + code + test. Only coding and testing have elements of engineering in them. Requirements managers are artisans.
Software developers are making progress in abstraction and re-use. We don’t write in assembler any more. We have code libraries available to minimize reinvention, even in higher level languages. Software developers are becoming more like engineers every day as their behavior becomes more an element of applying existing code than writing new code.

Requirements writers bear no resemblance to engineers. Like carpenters hand-crafting furniture, we have little or no reuse in our process. We are artisans. Since we are addressing a “new” problem with each project, we may always have to approach things as artisans.

Becoming Better at Requirements

We’ve shown before that having better tools for managing requirements won’t improve the quality of the requirements any more than a better saw improves the quality of a custom cabinet. Faster and easier, yes. But not better. Artisans improve with training and experience. This approach makes sense as the best one for improving at writing requirements.

Over the last month, we’ve written a series of 10 articles targeted at writing better requirements. The focus of this series is specifically on improving MRDs, and the linked article contains the summary of all ten, as well as links to the individual articles. Topics like removing ambiguity, validating the content with stakeholders, confirming feasibility with development – all key to preventing errors.

Conclusion

We should be investing more of our time improving our ability to write requirements, and write the right requirements. Maybe we spend so much on becoming more efficient at writing code because we know how to do that.

A plant manager can easily rationalize spending money to make his assembly line run faster. He understands the problem, and can measure the results.

$4 Billion dollars are being spent trying to solve half the problem. Imagine what would happen if we took just 25% of that, and spent it trying to solve the other half of the problem?

In fairness, our industry isn’t ready to absorb that kind of investment yet, so we shouldn’t make such a dramatic shift. How about 2%?

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

6 thoughts on “Companies Will Waste $1B This Year on Software Tools

  1. How can we call something as ‘software engineering’ when there is no such thing as ‘software science’?

    An engineering discipline should be based on solid theoretical foundation, a solid science. So called ‘software engineering’ does not have one.

    Ask the question ‘what is 1 meter’ to civil engineers, mechanical engineers, electrical engineers, and chemical engineers; and you will find one answer. Volt is volt, no other terminologies accepted. Many terminologies are well defined, well accepted, not confusing.

    Those luxuries are absent in the so called ‘software engineering’. Ask the meaning of the following terminologies to the so called ‘software engineers’. If you ask 9 people you get 9 answers

    – program
    – module
    – object
    – relational
    – object-relational

    This is very different situation with the answer you get by asking what is 1 meter to engineers in other fields. In other words, ‘software engineers’ do not deal with well-defined terminologies world wide.

    Related to that is the uniformity of terminologies. Linux ‘software engineers’ will use the terminology of shell script, but Microsoft ‘software engineers’ will use the terminology ‘batch file’. This does not happen in other engineering.

    Too many redundant and confusing terminologies: column, field, attribute, in the so called ‘software engineering’; not to mention about tuple, row, and record. Do we need that? Why not using only one (column, record)?

    Until at least these problems are fixed, there are no such things as software science and software engineering.

    Bernaridho
    http://www.bernaridho.com

  2. Berna, thanks very much for reading and commenting here! I’m actually going to disagree with some of your points.

    1)Software engineering is built on computer science – just as mechanical engineering is built on physics.

    2) There are both well defined and ill defined terms in engineering/physics and computer science / software engineering.

    You proposed examples of well defined (physical) engineering terms. There are also well defined software terms, such as recursion, A-star, kloc, etc.

    And you suggested terms that in software mean different things to different people. There are similar terms in the physical engineering world too. Motion and heat come to mind as perfect examples. Is motion the atomic vibration, or the orbit of a satellite, or a falling ball? Is heat the latent heat, absolute temperature, or a measure of potential energy?

    3) Terminology. Different disciplines of physical engineering look at the world differently too. Mechanical engineers will use Laplace transforms to study the time-domain of dynamic systems, while (analog) electrical engineers will use Fourier. They’re trying to solve problems that are different – perhaps the differences are nuanced, but the specialist tools have evolved to make solving the problems more efficient. The same is true in software.

    4) Confusing terms. Why do we need centigrade, Celsius, Kelvin, Fahrenheit, and Rankine temperature scales? Some of it is parallel development, some of it is solving different problems.

    I agree that it is annoying that different database providers have their own custom transactions and procedures that are incompatible with others. And it can be tedious when people use different names for the same thing.

    So, if these arguments prove that there is no “software engineering”, then there must not be “physical engineering” either. Don’t get me wrong – I’d love to see us address this stuff, but I don’t believe it precludes calling the field one of engineering.

  3. Hello to both of you. Found your interesting debate. Fresher as a business analyst but Scott agrguments have more weight.

    Conclusion: Scott seems right to me

  4. I respond to your responds. Readers, read carefully, meditate on this.

    1)Software engineering is built on computer science – just as mechanical engineering is built on physics.

    > Wrong. What part of software engineering that are just as sound as physics?
    > Physics have very sound theoretical foundation: the 7 basic units.
    Computer science (ignore about the hardware part, which is again based on
    physics) does not have such. To be precise: Software science does not exist, and therefore software engineering does not exist.

    2) There are both well defined and ill defined terms in engineering/physics and computer science / software engineering.

    > You proposed examples of well defined (physical) engineering terms. There are also well defined software terms, such as recursion, A-star, kloc, etc.

    > Hm, those are poor in comparison to the 7 basic units in physics.
    > What is the definition of recursion?
    > Must recursion be there in any program (software)? No. So it cannot
    be part of sound theoretical foundation.

    > A-star? Same.

    > KLOC? Kilo Lines Of Code. How can this be a sound theoretical
    foundation. It can bring too many interpretation. Look at the 7 basic
    units in physics. There is only one interpretation for any of the 7
    basic units.

    > And you suggested terms that in software mean different things to different people. There are similar terms in the physical engineering world too. Motion and heat come to mind as perfect examples. Is motion the atomic vibration, or the orbit of a satellite, or a falling ball?

    > How can the motion must be the orbit of a satellite? There is no such
    valid conclusion.

    Is heat the latent heat, absolute temperature, or a measure of potential energy?

    > It can be perceived from two or more perspective, but again the physics are based on a very sound theoretical foundation, the 7 basic units. Whether the latent heat is absolute temperature or a measure of potential energy can be investigated in more detail, but then the measure (of energy, of temperature) are based on the 7 basic units.

    > This is not the case with software. Even the KB OR MB cannot be the sound
    theoretical foundation for software since it is the units of physical storage.

    How do we define A-star, recursion?

    3) Terminology. Different disciplines of physical engineering look at the world differently too.
    Mechanical engineers will use Laplace transforms to study the time-domain of dynamic systems, while (analog) electrical engineers will use Fourier. They’re trying to solve problems that are different – perhaps the differences are nuanced, but the specialist tools have evolved to make solving the problems more efficient. The same is true in software.

    > A big mistake. You talk about techniques, not something analogous (which serves the same purpose) of 7 basic units. Using different transformations is like using different algorithms. Transformation is not equivalent to the 7 basic units. Indeed, the 7 basic units are more elementary, more basic than the transformation. People have used some of the 7 basic units before 20 century without using any transformations in practice.

    4) Confusing terms. Why do we need centigrade, Celsius, Kelvin, Fahrenheit, and Rankine temperature scales? Some of it is parallel development, some of it is solving different problems.

    > Those are scales, not the sound theoretical foundation. The sound theoretical foundation for Celsius, Kelvin, Fahrenheit, and Rankine is TEMPERATURE. Now, what is the sound theoretical foundation for software? You have not given any, and you have not even answered my question to define some terms in computing (module, program, object).

    Bernaridho

Leave a Reply to Scott Sehlhorst Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.