Techniques

This book consists mainly of techniques for software development. A technique is:

Examples of techniques in this book

Tools, Not Rules

A common mistake is to confuse techniques with "best practices" — things you should always (or almost always) be doing. This isn't how I think of the techniques in this book. Techniques are tools, not rules. Each technique helps to resolve some of the Forces that often arise in software systems, but every system is different. I see some of the techniques as reasonable defaults — approaches to try first if you don't know what else to do — but all of them are context-dependent and none are required.

If you treat techniques as "best practices," you're likely to fall into the same trap that I have seen too many teams get caught in — you will end up creating solutions that are far more complex than required, and even you will find them Alienating and hard to use.

Choosing Techniques

Which technique should you apply at any given moment? As I will explain in the chapter on Judgment, answering this question is the essence of a software developer's job, and there's only so much guidance I can give you. Still, this book can help in a few ways.

First, I have marked the chapter headings of "default" techniques with a star (✥). I recommend trying these techniques out, and discarding them only when you have demonstrated that they don't apply to your situation.

Second, the principles and views in this book can help you evaluate each technique in your context to figure out if it applies. This approach becomes intellectually tractable once you have a diverse array of techniques committed to memory. Once you've practiced the techniques in this book, relevant techniques will pop effortlessly into your mind whenever you see a problem or an opportunity. Your job then becomes to apply the technique (or in some cases, just to imagine applying it) and to Judge the costs and benefits. If the benefits outweigh the costs, use the technique; if not, don't.