This article takes a look at decision making and in particular how to make better decisions especially in choosing whether to write a new software product, buy some software or not implement a software solution at all.
In writing this, I came to a realization. That software whether written by one person or thousands is the culmination of decisions. As the saying goes your life is the sum of your decisions so is software. Intuitively people have been striving to create tools and frameworks for making decisions for example best practices, design patterns, and software methodologies. Software methodologies at there core fulfill some or all of the following:
- The ability to give decision makers a strategy for making optimal decisions for that software
- Tools for decision support
- A list or road map of major decisions to be made i.e. architecture, requirements, testing strategies, tools to be used
- The ability to detect and correct suboptimal and non-optimal decisions
- Mitigate the risk from suboptimal and non-optimal decisions
- Communicate the decisions that have already been made, what decisions need to be made, and how to chose the optimal decisions
- Measure the progress and the chance of success
However, in all the reading on the field that I have done over the decades, I have found few articles that answer these questions:
- How do you make decisions?
- How can I increase my ability to make good decisions?
- Can a framework for making software decisions be formulated?
- Can you measure the quality of a decision?
- What is an optimal decision?
- And most important how do you string together optimal decisions to have a successful software product or application delivered in a repeat fashion?
This article explores these questions and the questions that come out of that exploration.
What is a decion?
Let's start with the easy stuff the mechanics of a decision. The Merriam-Webster definition of a decision:
1 a : the act or process of deciding b : a determination arrived at after consideration : CONCLUSION 2 : a report of a conclusion 3 : promptness and firmness in deciding : DETERMINATION
Not a lot of help but essentially a decision is the result of making a choice. For example, choosing between programming in C# or VB. Using a “for” rather than a “while” loop. Both have choices to be made. And those choices bring consequences both intended and unintended. Ultimately, one or more people make a single choice and hence a decision.
Another aspect of decisions is that there are levels of importance and impact. For example, while coding, experienced programmers think very little about each line of code. In fact you could say that it these small decisions are reflexive decision. We spend more time with algorithm design and class design. Overall architecture and strategy require more attention and consideration. As you get up further in the development hierarchy your decisions have more impact as do earlier decisions like architecture, tool, design, and process decisions.
The Effects of Decisions
Decisions not only have impact the moment they are made but ripple out. And multiple decisions have incremental or even expontential impact to a project. Just as some people would say that you are the sum of your choices so are software projects and applications. For example, in the 1990's people at Microsoft made decisions based on making the user experience easier. The intended consequence was rapid adoption of Windows and Office. The unintended consequence was a platform that was insecure.
Here is another example. I worked on a project which was the fifth attempt to replace an existing corporate application. Interestingly enough the fourth attempt was about 80% complete, however, it was decided to rewrite the whole application. Why? The cumulative decisions had negative impacts on performance, maintainability, and extensibility of the application. Was this just the culmination of bad decisions? If you look at each decision in isolation I would say that each individual decision on the whole was a good decision. To be clear looking back some where bad decision but at the time and with the available information the decision was a reasonable choice. Just like Microsoft's choice to focus on easy of use and integration. Looking back it looks like a bad decision however at the time it served its purpose the expansion of the Windows and Office platform in the market place.
At every level, developers, managers, and domain experts made good decisions at the time in writing the fourth version. And yes they made some bad decisions as well but no one decision stands out as just being glaringly obviously wrong. Rather it is my belief that the project lacked a framework for making decisions. This is I believe a critical point. Decisions in a vacuum become a crap shoot for the overall cumulative effect and without a framework to guide the decision making process, what is a good decision on one project can be a bad decision on another.
While we are on the topic project failure it is interesting to note that project failure rates have declined in 10 years (see Chaos Reports). The percentage of projects that failed or had some significant issues in 1994 was 84% and in 2004 it was 71%, a change of 6% per year. Not bad until you find out that a majority of the change came in a two year period from 1994 – 1996. So the real rate of return in the last eight years is less than 1%! I do not want to down play the complexity of software however if our business leaders failed this much the economy would be much worse off. If business units can make cumulative decisions that improve productivity, revenue growth, and profits; it might be worth looking at what they are doing right i.e. decision making which leads us directly into my next two questions:
- How can I increase my ability to make good decisions?
- Can a framework for making software decisions be formulated?
I will start to cover those in my next posting.
