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.
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.
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%?
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
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.
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
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
Thanks very much for commenting. We just have to agree to disagree.
And thanks Yogesh, sorry – I almost overlooked your comment. I appreciate it.