Techniques, Principles, and Views
Hello! You’re reading Ben’s Guide to Software Development, the weekly bulletin where I post draft chapters of my upcoming book, Process to Processes. You can read the whole draft (at least, what I’ve written so far) by clicking this button:
…and if you’d like to get notified of updates to to the book, you can sign up with your email below:
What I Learned This Week: Example Blocks
A certain dilemma has been bothering me recently. I want to include a lot of examples in the book, because there’s evidence that people learn best from seeing lots of high-quality examples.1 But examples take up space, and break up the flow of the text. Readers who are already familiar with a topic might prefer to skip the examples, but the nature of examples is to sprawl, and that makes them difficult to skip.
This week, I came up with a solution to the dilemma. It’s nothing revolutionary, but I suppose that’s the best kind of revolutionary.
The solution is to put examples in a collapsible <details> element. This nifty bit of HTML looks like this:
<details>
<summary>Examples</summary>
<p>Our first example is...</p>
</details>When the page loads, only the summary is shown. You can click on it to expand or collapse the whole details block.
This approach isn’t directly portable to dead trees, of course, but since I’m already embedding videos in the book… “returning were as tedious as go o’er.”
You can see an example of examples in the chapter on Principles.
Techniques, Principles, and Views
Today’s post includes three short chapters from Process to Processes, introducing the concepts of techniques, principles, and views. Here are the chapters:
Techniques
This book consists mainly of techniques for software development. A technique is:
something you do
...to solve a problem or pursue an opportunity
...in a particular context.
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.
Principles
Principles are idea-generators for coming up with new Techniques. If we’re in a situation where our known techniques don’t apply, we can use principles to invent new techniques that are suited to that context.
Examples of principles in this book
Each principle prompts you to ask a different “how might we” question. “How might we take smaller steps?” “How might we get feedback faster?” “How might we avoid breaking changes?” “How might we move authority to information?” “How might we reduce inventory?” By brainstorming answers to these questions, you can discover new techniques. You can also assess existing techniques to see if they might be the answer to the question.
Where Principles Come From
Principles are derived inductively from clusters of related techniques. The process goes like this:
Look for similarities between techniques
Infer a principle that explains the similarities
Test the principle by using it to generate new techniques. A principle is useful to the degree that it helps you discover useful techniques.
This process echoes the scientific method, which we’ll see shortly in the chapter on Empiricism.
Wait a minute, you’re probably saying. Do techniques generate principles, or do principles generate techniques? I can only answer “yes.” Principles and techniques work together. Like so many other symbiotic partners in the world of software, they bootstrap each other into existence.
Views
Point of view is worth 80 IQ points.
Supporting the Techniques in this book are a number of views. A view is a way of looking at things. To put it another way, a view is what you see when you look at some part of the world from a particular metaphorical angle.
Views matter because they give us an effective way of seeing. Like an architect’s plan, a view describes the world in terms that clarify how we might act on it via techniques.
However, just as the plan of a building doesn’t tell us what it will look like from the front, a view isn’t the whole picture. In order to build mental models that capture all the facets of reality, we need to combine multiple views.
Accordingly, I often use collections of multiple views in this book when investigating complex topics. For instance, the next section (SoftwareDevelopment) opens with a collection of views of programming. Sometimes I present only one view of a topic, e.g. Centers. This is generally not because that view is the only useful one, but because the other views are common knowledge and I don’t think there’s a need to reiterate them.
In any case, it’s important to remember that views are not true. They are, necessarily, simplified descriptions of reality, that can’t account for every complication. The question you should ask of a view is not “is it true” but “when is it useful?”
For example, I might show you a program and say “this program has no State.” You might protest “but it caches the result of some calculations, and those caches have state.” “Well, if we just want to describe the program’s Behavior, we can pretend it has no state.” “But the caches affect performance.” “Well, for now we can pretend computers are infinitely fast.” Views are all about simplifying things in this way — removing detail until we are left with only what is essential to serve our current purpose.
Views Versus Models
A mental model is a holistic understanding of a system. Mental models are what allow us to make predictions about the future. They let us simulate the system in our heads, and imagine what it will do in response to some outside stimulus or change.
A weakness of mental models is that they can never be fully explicated or communicated from person to person—a point that Peter Naur makes well in his essay “Programming as Theory Building.” He uses the word theory where I use “mental model”, but it’s the same idea.
Indeed, I would go so far as to say that a mental model is not built, but grown. It is rooted in a particular mind, developed through the interaction of that mind with the world, and can never be moved.
Because we can’t directly communicate our mental models to each other, we need views. Views are more teachable than mental models—we can explain how to obtain them, draw pictures representing them, and so forth. The downside of views is that, in general, no single view presents a comprehensive picture of the system it describes. But by combining many complementary views together, we can form working mental models much more easily.
Views and Techniques
Views and techniques go together. A common saying, often attributed to Abraham Maslow (though he never said it in so many words) is “if all you have is a hammer, all you will see are nails.” But the converse is also true: if you see the world in terms of nails, the only tool you will be able to imagine is a hammer. The diversity of views presented in this book is necessary to support the many different techniques we will cover.
Here’s an example of views, techniques, and principles all working together. Say you’re working on some code that’s difficult to understand: you have to jump around between many different files and functions to figure out what it’s doing. The view DependencyGraph gives you a way to make sense of the code in spite of its complexity. The principle ShallowHierarchies builds on this view, identifying a specific property that makes the code frustrating to work with — the dependency graph is too deep. Techniques like InlineFunction and InvertControl apply the principle, giving you concrete ways to fix the problematic code.