Atomic Spin :: Elements of Software

Risk and reward are as intimately entwined in software development projects as they are in any other aspect of life. Higher risk goes with higher reward. Lower risk projects can expect lower returns. Tim Lister recently helped me better understand risk. He points out in Waltzing with Bears that the common goal of “eliminating” risk is not only infeasible, but undesirable. If you could truly take all risk out of a project you’d also be removing all potential reward. The risk in a software project represents everything you don’t know or can’t control. And it is these very elements that usually make the project interesting and potentially valuable.

Risk elimination is naive and fundamentally wrong-headed. Risk management, on the other hand, is a way of responsibly addressing risk. The agile software development community has brought attention to practices that manage risk. Starting with a minimal working system, continuously integrating the efforts of all team members, automating for regression testing, pair programming, keeping the system running during the entire project, managing projects by data rather than from a static plan—these practices are all aimed at responsible risk management. They, and others like them, have an underlying theme of managing the risks common on software projects.

Software projects worth doing have risk, and usually the ones with the biggest risk have the biggest potential reward. Agile development practices can help immensely in managing common risks. But management isn’t elimination (thankfully), so there remains a question of how the business relationship between a software customer and a software development vendor will be crafted with respect to risk.

When you buy property, automotive, or health insurance, you are paying someone else to assume some risk. A customer who wants a firm, fixed-price for a software project is asking the vendor to assume the risk that the requirements are incomplete or ambiguous, that the technology chosen will have unforeseen issues, or that the problem is more difficult to solve than originally envisioned. Vendors, at least those responsible enough to stay in business long-term, naturally protect against this risk by adding some inflation factor to the project estimate. The biggest risk is typically the ambiguities and hidden complexities inherent in interesting projects.

If it were possible to reliably, accurately, and completely specify projects up front, this model of paying the vendor to assume all risk would be a practical business relationship. But projects, particularly interesting new product development projects, are simply not this way. Interesting, risky, valuable projects have requirements that evolve over time as new information from the customer, the users, and the developers is fed back into the project. Fixing the requirements and the cost of a project at the point of maximum ignorance - before the project has even begun - is bound to result in difficult change. Much time and energy can be devoted to arguing over a specification or the nature of a change. This contributes nothing to building the best possible software. In the worst case, the vendor and customer both resist good changes which arise during the project because it isn’t “in the spec” or “in the plan/budget”.

Customers should expect developers to manage risk through their status quo development practices. They should also expect that they will pay to transfer risk to the vendor. Lastly, and most importantly, customers must understand that the highest potential reward comes from the projects that are most difficult to completely and unambiguously specify before starting.

Part of a series entitled Software Customer 101

Course Outline and List of Lessons

Previous: The Nature of Complexity

Next: “Mission Impossible: complete, accurate, unambiguous specifications”