Tuesday, April 22, 2014

Making choices

A good enough choice made on time is better than a belated best choice

This has been my motto when making decisions. Do not get paralyzed by the fear of not making the best decision. As long as you make good enough decision.

After all, Software systems are complex and there is hardly ever a "perfect" answer to a problem. If spending 20% of the effort you can get an 80% good enough answer which is probably the right answer why waste your and everybody else's time.

Be lazy: Reduce the effort you put making choices. 

Of course, we know that making a quick decision does guarantee a good enough answer:

- The teacher asks little Johnny: Jonnny, quickly, what is 2 times 5
- To which little Johnny immediately replies:  It is 11, teacher
T - Johnny that's wrong!
J - You asked for speed, not accuracy.

But there are techniques to help you make quick "good enough" decisions

Some of those are explained on the TED talk How to make choosing easier.

In future posts I will expand each of them showing specific examples on how to apply these techniques to software development.

Cut - Reduce the number of alternatives;
Only decide between options that make a difference. In fact, in some cases you can reduce the options to 1, which reduces the effort to 0. To help you cut on the options you can use Patterns, Frameworks, Standards Guidelines.

Concretize - Make it real;
When evaluating options, weight the actual project requirements to make the final decision relevant. 
I've seen people evaluate designs, libraries or tools based on "features". While that makes for a good magazine article, it is usually misleading and usually leads to a least than optimal decision. Compared feature by feature one of the options may have more customizations or better support or be the favourite of (insert your tech guru here) but it may not be the best option your project. 

Categorize - we can handle more categories, less choices each
Don't try to make all decisions at once. Categorize the decisions by impact, area of the system or areas of responsibility.
A very common trap when making architectural or design decisions is trying to make all decisions at once. There are so many decisions to make that we get paralyzed and feel that we cannot start the project until we have made the right choice for each of them.

Condition for complexity - Gradually increase the complexity of the decisions.
This one of course goes along the three techniques above. After cutting, concretizing and categorizing; start by making the decisions with less options earlier, That will give you a sense of accomplishment and will probably drive other choices down the road. In fact, having many options usually means that the difference between them is not that big.

But wait, there is more!
As you see all of those techniques provide frameworks to help you make decisions, but they are not the only ones. In future I will tag as "Choices" post that I identify a posts, that can help you make better decisions. 

Do you have your favourite techniques?


No comments:

Post a Comment