Decisions

Everything you do has two parts: the decision making and the manual labor. For example, when you are coding, you first decide what you want to write and then you type it. Often the two parts are so intertwined that it is not practical to separate them, other than conceptually. When you start typing a function you rarely know exactly what you will write. Instead, you continuously make small decisions as you go.

The decisions are the important part. A well-trained Neanderthal could do the typing. But to do the right decisions you need skill and experience.

An obvious way to improve productivity, then, is to add the number and impact of decisions. There are a number of ways:

  1. To give more room for decisions, reduce the time spent on manual labor. This is the virtue of laziness, as popularized by Larry Wall:

    Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so that you don’t have to answer so many questions about it.

  2. Many decisions are not important but they have to be made. Naming conventions are a good example: when choosing between CamelCase versus ALL_CAPS in constant names, the actual choice doesn’t matter as long as one of them is used consistently. To improve the impact of each decision, let someone make these less important choices for you. Use an existing pattern, or a framework that has reasonable defaults. David Heinemeier Hansson thinks this was one of the main reasons for Rails’ success. Rails has made the choices so you don’t have to:

    Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn’t pass judgement on one form of development over another. Well, Rails does, and I believe that’s why it works.

    With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I’ve embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.

    […]

    One characteristic of opinionated software is the notion of “conventions over configuration.” If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you’re rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that, which all add up to make a huge difference in daily use.

  3. Distribute decision-making. If a tech lead makes every decision by himself, he ends up using his valuable developers as Neanderthal typists. The better way is to push the decision making down to the developers. They have the best understanding of the code base. If they also have an easy access to customers they are in the best place to make many of the decisions.

And after writing this, I now realize these are all instances of the same advice: make each decision only once. Essentially, I just repeated the DRY principle three times. Ironic, isn’t it?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s