Taking Decisions

This post is not a coherent text or story but a collection of thoughts about taking decisions in a software project. The idea to blog about "taking decision" arose when in one of my company's project recently everything went wrong. The lead developer disappeared (really, never seen him again!), no design documentation, we had to dig for what design was intended...
We had to get the project back on track as soon as possible. We had to take decisions!

My summarized thoughts in mantra style

There are no right or wrong decision, there are decisions suited better or worse for the current requirements.

You can evaluate the quality of a decision only in the future with changed requirements, new requirements or a fully changed environment.

If you want to take a decision in a group first step is to find and write down assessment criteria. Develop a consistent understanding of your assessment criteria.

What's worse than a bad decision is no decision.

Take requirements that are likely to be changed into consideration. If that makes your decision taking process to complex don't do it.

Using a strategy pattern is no decision. It's a deferred decision. You will have to take that decision in future.

If you stumble about the product of a worse decision in code - change your decision.

Decisions are subject of change! Accept that not all of todays decisions will not stand the test of time.

Don't be afraid to take decisions.

Don't treat decisions equal. Evaluate the impact of a decision, take time for decisions with a
high impact, take trivial decisions fast.

Communicate decisions!