Let's start by looking at what tools exist for making decisions. There are many tools for making decisions in the business world including decision trees, grid analysis, paired comparison, cost benefit analysis and Pareto Analysis (80/20 rule) to name a few (see Mind Tools additional tools). Other useful tools from the software world are best practices and design patterns.
These tools can help in a variety of ways from the very high level, high impact decision, to more mundane decisions when actually coding. The Mind Tools article provides a rich source of information and I will not rehash it here. However, I will show you how these tools can be used in making software decisions.
Paired Comparisons
Paired comparison is can be used to evaluate various options in relationship to each other. Using this technique one can look at weighing various technical goals for a product. Technical goals include items like code maintainability, performance, extensibility/flexibility, and stability. These are important goals however unlike features end-users have only vague ideas as to which would be important to their specific project. Using paired comparison you can rank these technical goals against each other.
Paired comparisons can give you insight into the relationship of these goals to each other. By understanding these relationships you can begin to formulate an overall strategy for guiding decisions about the software. For example, if performance is the number one priority of the technical goals when faced with multiple choices I would chose the option that gives me the best performance which is probably the least flexible and maintainable.
So take for example Microsoft's use of providers in .Net 2.0. This model allows for replacing the actual implementation with little or no change to programs setup to use providers. It allows for great flexibility while minimizing the performance hit. Note that a deliberate decision was made to take a performance hit. Then because performance was still very important, the actual implementation of the provider model took into account performance. So for example, when I first saw providers I thought why did they not use interfaces. After all interfaces are about defining a contract between the consumer of the interface and the implementer of the interface. Instead the model used an abstract class. Why? It turns out that using an abstract class rather than an interface is faster. A minor difference but still curcial based on design goals.
This is important; you must have an overall strategy for decisions. Paired comparision can be used to help understand the trade offs. Looking back at the project I mentioned above it was a lack of overall decision making strategy that lead to a sequence of individual sound decisions into a failed project.
The next entry will look at Cost Analysis. Cost Analysis is extremely useful for someone interest in product development. It is very useful for understanding what you should charge for your software and even if you should write the product.
Comments