- We Fail Too Much
- Definitions of Success
- The Standish Group
- Doing the Wrong Things
- Doing the Things Wrong
- Time Goes By, Things Improve
- One Reason: The Civil Engineering Analogy
- Giving Up Hope
- Ignoring Your Mother
- Bridges Are Hard, Software Is Soft
- We Swim in an Ocean of Change
- Accept Change
- Embrace Change
- Capitalize on Change
- A Better Analogy: Evolving Systems
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Definitions of Success
What defines success in software development? In summary, a software development project is successful if it delivers the value expected for no more than the cost expected. This means
- The software is ready on time.
- Creating the software cost what it was supposed to cost.
- The software does what it needs to do.
- The software is not crippled by bugs.
- The software gets used, and does make a positive impact. It is valuable.
The first two, of course, are often related to each other. The time we spend to make software is a big part of the cost, because the largest cost is developer time in the vast majority of projects.
However, I have been on projects that delivered on time, but required the efforts of a lot more developers than was planned for, so the project ended up costing more. Either way, when we are late or over budget, we harm the business we are trying to help; it often has plans contingent on the release of the software, and having to change those plans can be expensive and sometimes harm its relative competitive position in the marketplace.
The third point, which could be called functional completeness, is of course a relative thing. Software could always "do more," but the real question is whether the software does the most critical things it was needed to do, and therefore has a potential for a positive impact that is commensurate with the cost and effort it took to make it.
No software is free of bugs but there is a clear difference between software that fundamentally works, with a bug here or there that will have to be remediated when found, and software that is so buggy as to be unusable.
Sometimes software that is delivered "on time, on budget" is not actually finished when it is shipped, which becomes clear when we find a lot of bugs, or find that a lot of crucial features are missing.
In the final analysis, the real critical issue is: Are they using it? How much value is it producing in the world? I think that sometimes we have taken the attitude that this is not in our scope, not our problem. We made it, it does what we promised, and it works, so if they do not use it, then that is their problem.
I do not feel that way anymore. I don't think we can.
First, if the software is not being used, why is that? Perhaps the problem it was intended to solve has disappeared, or changed so much that the software no longer addresses it well enough. Perhaps the customer was wrong when he asked for features x, y, and z, and found out too late for me to change what I was making. Perhaps the software works, but is too hard or unpleasant to use, and people shy away from it.
Whatever the reason, software that sits on the shelf, unused, has no value (see "Appendix C, The Principle of the Useful Illusion," for my thoughts on this). In a sense, software that exists only as little reflective dots on a CD-ROM and is never running, does not really exist at all in any useful way.
I do not want to spend my time on valueless things that do not really exist, do you? I think one of the attractive things about software development, at least to many of us, is the idea that we can make things and that these things actually work (and do something useful). That an idea, something that starts in my mind, can have a life outside of my personal domain is a little bit magical, and it is what got me hooked on computers and computing in the first place.
Also, I want to go on doing this. I want to have lots of opportunities, and to be able to choose from a wide variety of projects, choosing the one(s) that are most interesting to me. If software does not deliver sufficient value to the people who pay for it, I don't think this is likely to happen.
So, if we can agree that this checklist is right (or at least close to right), the question remains: How are we doing? Luckily, someone took on the task of answering this question for us.