The Four Rules of Simple Design: In Conclusion

Brian Hicks, August 25, 2021

OK, it's been a couple of weeks since I published Rule 4: Code for Now, and I've had some interesting feedback!

The biggest thing first: how do you apply these? Surely you don't just go down the list one at a time, right? Well, no, I view it more like like a state machine: you enter at Rule 1: Simplify When the Program Works and move from there back and forth between Rule 2: Clarify Your Intent and Rule 3: Centralize Behavior. Once you think you're more-or-less done, you check your work with Rule 4: Code for Now. When you don't have anywhere else to go—that is, you don't see an opportunity to apply any of the rules—you call it good and move on to the next thing you need to do that day!

That's not the only way to apply the rules, of course, but it's one that I've found works pretty well for me. J.B. Rainsberger applies the original rules something like this as well: see his post The Four Elements of Simple Design for more, in particular his axioms of modular design.

Of course, it's not the only way by a long shot! One of my colleagues at NoRedInk pointed out that he'd like to rearrange these rules:

Code for now
Simplify when the program works
Clarify intent
Centralize behavior

That could certainly work too! It's up to you how you apply these, if you want to apply them at all.

There's also some tension between the rules. For example, in Rule 3: Centralize Behavior I talked a lot about making a Point2d class. But… is that structure really necessary? Couldn't it violate Rule 4: Code for Now? How do you decide which to apply? In the end, you've either got to choose randomly or find a tiebreaker: for example, you could use Sandi Metz' Rules For Developers, which emphasize very small classes. In that context, building a Point2d may or may not be OK depending on how close your class is to 100 lines.

Personally, I've usually gone the other way over the time: I've randomly chosen to prioritize rules randomly based on the situation at hand. However, since part of the appeal of this whole exercise is that they allow us to reduce guessing about the future, I'm going to continue to explore situations where there seem to be holes or conflicts!

And, to that end: if you read through the original sources (or mine) and are inspired to make your own remix of the four rules, I'd love to read it! Please send me your takes! Let's build on each other's work to discover how to make better software.

Thanks for reading!