Strawberries 3: Simple Design

I know what you’re thinking: ‘Is this four rules or only one?’ Well, to tell you the truth, in all this excitement, I kind of lost track myself. You’ve got to ask yourself one question: ‘Can I use this?’ Well, can you?

Among the eminent Kent Beck’s many contributions are his four rules of simple design. My preferred formulation is this one:

The code is simple enough when, in priority order:

1. It passes all the tests;
2. It contains no duplication;
3. It expresses all our design ideas about the code;
4. It minimizes programming entities.

Kent has expressed the rules a few times, and sometimes reverses the order of #2 and #3. I prefer this order and I’ll tell you why, later on. Let’s work through the rules one by one:

Passes All the Tests

If the code doesn’t work, there is no point simplifying it. If we don’t know that it works, we really need to determine that before “improving” it. This rule is critical, and leads to Test-Driven Development, which will be at least one topic in this series, and perhaps more than one.

There must be sufficient tests to know that the program works, and it must pass them all.

Contains No Duplication

At its surface, this rule prevents copy-pasta, the copy from here paste to there practice that leads to spaghetti code. But it does much more than that. When two or more chunks of code look similar, there is almost invariably some common idea trying to be born. Perhaps it’s as simple as “apply some function to all the elements of a collection”, or as complex as “set up a network of collaborating processes”.

Whatever the idea that’s waiting to be born, removing the duplication is our path to discovering what we actually we going after when we wrote the stuff. We illuminate the similarities, break out the difference, and soon an idea starts to take place. Personally, I often find that it’s only in looking at the code during duplication removal, and after it, that I really see what my own idea was.

There are many more forms of duplication than just “this code looks like that code”. Sometimes it’s just that “this happens a lot, but we could make it happen only once”. Duplication in time rather than space.

Looking for duplication and removing it is an incredibly powerful design approach, especially when combined with the next rule:

Expresses All Our Design Ideas

Most of us have the experience of looking at some big block of code and suddenly understanding a chunk of it. We point at it or draw a circle or highlight it and shout “Eureka¹, I see what it’s doing here!”

When we have that experience, we owe it to the world to extract that chunk of code into a function or subroutine or method and give it a name that expresses what it’s doing. Next time through, the reader won’t have to puzzle quite as long. And, once that chunk has its own state of being, the remaining larger chunk often becomes more clear as well.

When the code expresses our design ideas, they come quickly to mind as we review it, and they become easy to change as we need to.

Minimizes Programming Entities

The other rules being satisfied, we’d like to have as few functions, classes, methods, modules, files, variables, trumtookas, whatever elements there are in our program. Once we’re removed duplication and expressed all our ideas, there is no purpose for any entity that isn’t there as the single representative of a single design idea.

If there do seem to be too many entities of some kind, it is most likely a lurking kind of duplication, or a design idea waiting to be discovered and expressed.

Minimize programming entities, subject to the other rules.

Duplication Before Expression?

I promised to discuss the ordering of rules #2 and 3:

2: Contains no duplication;
3: Expresses all our design ideas;

Now the truth is, if these two rules are ever in conflict, then there are two or more things in the code that look like duplication, but there is some design truth that makes that breakout “correct”. That is:

If removal of duplication and expressing ideas are ever really in conflict, choose to express the ideas.

But since the rules are supposed to be in priority order, why then, do I put the duplication rule ahead?

I do it because it is such a powerful tool: Duplication is generally very easy to spot. Removing duplication requires us to express the code’s design better as we name the removed chunk.

I put checking for and removing duplication right after the tests going green, because I can build the habit of using it as the entry point into the “refactor” stage of “Red, Green, Refactor”, the core of another great Kent Beck idea, test-driven development. We’ll surely talk about that very soon.

Summary

One rule or four, they go together:

The code is simple enough when, in priority order:

1. It passes all the tests;
2. It contains no duplication;
3. It expresses all our design ideas about the code;
4. It minimizes programming entities.

Maybe it’s one big Strawberry, so juicy and delicious that it takes four bites to enjoy it. Maybe it’s four lovely little Strawberries. Don’t really know, don’t really care.

One or four, these rules work well for keeping our design as simple as it can be.

These rules make me feel lucky.