Timing & Decisions

time to read 2 min | 387 words

When you should make a decision? This is an interesting question that goes beyond software design and into real life as well. I thought that I would share my philosophy about making decisions, and when I make the final cut.

The issue here is not about split second decisions, of course, it's about those decisions you've time to prepare for, but may not have all the data avialable. From development, it may be that you're considering the design of your application, but you are also waiting for the release of some component that you depend on. From real life, you know you are going to get a new team mate in two weeks, but you're not sure what his abilities are.

I had to make many such decisions while I was in the army, and I learned one thing. If I can do it at all, it was best not to decide until I had to decide. Each and every time that I tried to make a decision base on partial information, I was wrong. Most times, even when I did have all the information, by the time that decision was relevant, it wasn't the right decision. Since then, I adopted a philosophy that basically says:

Never make a decision until the time that decision is relevant.

This doesn't mean that you need to wait until you've all the information, often enough you have to make a decision before you've the information. But waiting will usually give your more information that you had before. One thing that this technique require, though, is that you'll consider all the options that you have to make this decision, without trying to find the best one. (I can put the new guy on Marketing, R&D or QA...)

Exploring the options will make sure that when you need to make the decision, at least you'll have a good idea about what are the implications of the decision. I have found this to work in most areas of life, and I attempt to apply it whenever I can.