"It depends" / context on creating software products (I)

"It depends" is the standard consultant answer to any question. It sounds like a joke, but in fact, it is an excellent answer.

If we are involved in creating software products, our day consists of making a lot of decisions. We have to take decisions at very different levels, for various purposes, and with different importance level:

• Constant micro decisions when developing and designing software (what is the next test? should we remove this duplication? should we divide this class? what is a good name for this method? and for this module? etc.)
• Constant Architectural decisions about macro design, practices, strategies, etc.
• Sometimes estimations (or even better, how to split the features into small steps, so we don't need estimations).
• What are the optimal priorities for the next tasks to accomplish?
• Wich experiments can we define to validate a hypothesis?
• Wich technical debt should we pay right now? 
• etc.

Making decisions is hard, very hard...

In my experience good tactics to make decisions in our profession are:

• Know as much as possible about the context (business, purpose, why you need to decide about this, etc.).
• Minimize the risk associated (for example pushing for reversibility when possible).
• Postpone as much as possible (to gain more awareness about the problem, the context or the risk).
• Simplify to minimize the number of decisions needed.

And here is the problem. I usually see very little awareness about the context in which we develop the software.

This lack of awareness is why we can waste a considerable amount of energy discussing dynamic typing vs. static typing, optimize runtime performance vs. developer productivity, should we use cloud/containers/microservices.

Everyone is right, or everyone is wrong, depending on our point of view.

If we don't know about the context, the decision is always wrong :)
So "it depends"!!! (on the context)