The Mindset

In the previous Elements Of Simplicity post I discussed the importance of proper research to the simplicity of the design and code. Today we’ll discuss the next step toward simplicity: being decisive.

What does being decisive have to do with simplicity? See if you find this scenario familiar.

You are working on a system architecture. You’ve already identified some of the components in the system, but you can’t clearly draw the line between them and define the responsibility of each component.

Well, it’s not that you can’t. The problem is that there are some conflicting considerations. You find it dificult to decide which responsibility belongs to each of the components. So, you decide to consult your colleagues and the development team. But the more people you ask, the more confused you get. Everyone seems to have a different opinion with a new rationale to justify it.

The project manager is breathing down your neck, so you decide… not to decide. You define each of the components as vaguely as you can and hand your architecture to the development team.

The problem is that the decision still has to be made. The developers who are responsible for implementing the vaguely defined components now need… well, to implement them. With no clear definition of each component, every developer might understand it differently. With every new feature that has to be implemented, the discussion about which component is responsible for it is spawned again. And with no clear definition of each component, each such discussion starts from square one.

After two months of development you end up with a bunch of incoherent components. Trying to understand the system and each of the components within it becomes extremely difficult. Each extension to the system seems to break some of the components. New features are difficult to fit into the system’s incoherent architecture. The system becomes complex.

The Easy Way is not (Always) the Simple Way

Some decisions are hard to make. Design and architecture decisions can be particularly difficult. Most design decisions are not definite. There are pros and cons for each decision. It may look like the easiest thing to do is not to decide. But, in most cases this will only make things more complex.

When you avoid making a decision, you send an ambiguous message. Everyone can interpret it as he sees fit. So everyone does. This is a sure recipe for endless (and futile) discussions.

When you are reluctant to commit to a decision, you open the door for contradicting ad-hoc decisions, which turn the design and the code into a melting pot of fragmented inconsistent ideas. This is how complexity is born.

Not making a decision is also a decision. But it isn’t like other decisions. In most cases it’s the worst decision you can make.

Even when you find it hard to decide which option is best, do whatever you can to make a decision. Leaving things hanging in the air will not solve the problem. It will just make things more complex. If you can’t decide what’s the best option, how will your developers decide?

Remember that you can always change your decision later, as long as you do so consciously and after a serious analysis. This is not the best thing to do, but sometimes it is unavoidable. In any case, it is by far better than not making a decision in the first place.

Make a decision. This is what you are paid for!

This entry was posted on Friday, June 23rd, 2006 at 11:42 pm and is filed under Design, Complexity, Simplicity. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.