Imagine stepping into a foreign kitchen to prepare an enchanting diner. Compared to cooking at home, how fast are you likely to be? You may be a great cook but not knowing where to find the ingredients will slow you down. Some rules apply. Objects and kitchen goods are usually not placed completely at random. Unless your friends intend to mess with you and do it on purpose ; then you're screwed.
In the previous part, we saw that "making it work" was paramount. So is feeding your guests once in a while. So is serving them a sauce that is not 142% to your liking, but still "real damn good". So is relieving their hunger before they order a pizza. This was the previous article.
Assuming you understood this and do intend to feed them soon. What could prevent you from doing so? Imagine stepping into the kitchen and finding it in a post frat-party state of chaos. How is that going to slow you down? You will have to make room on the kitchen counter. You will clean up some tools. You will search the salt everywhere and will find it next to the tequila in the bathroom. This is what happens when you stop after "making it work". That's the hell of a party, but you need to clean up afterwards.
If you want to survive in the business of having friends over for diner, you are going to need a few rules.
First, you clean up right after use. You swipe on a case by case basis and not delay it as long as you can, until someone feels the urge to do it for you.
Then, objects are not placed at random in the cupboards but ordered in a logical, intuitive way. As a rule of thumb, objects should be closer from the place where they will serve. The frying pans are somewhere close to the stove. Knives and cutting boards are in close vicinity of the kitchen counter and one another .
Finally, conform to some standards. Unless you craft your very own recipes, follow steps written by others. Allow your body to build automatism. Learn the rituals of your craft. It will help you converse with your peers.
Now let's imagine you are being helped by one of your guests. He or she isn't familiar with your kitchen and don't know the recipe. Would it be easier for them if your kitchen was clean and tidy? If your kitchen followed some common sense standard as mentioned above? What if you had to excuse yourself from the kitchen? Could this person pick-up where you left? Could the cooking go on while you run to the door and find your starving guests paying the pizza delivery man?
I've stretched this analogy as far as it can get. The same idea of tidiness must apply to our code bases. Cleaning our code right after writing it makes "future-you" more efficient. Writing clean code enables shared responsibility and thus flexibility.
When your code is not clean enough, you create pain points that will hurt you one way or another in the future. It will prevent you from adding new features or scaling out teams. You can work with sub-par code for a while and not feel cornered by the pain points right away. Exactly like you can very well cook a nice diner with the sink already loaded with some dirty dishes. Still, good code will always end up being more productive. It will help you clarify your thoughts and will help you on the long run.
Assuming we reached an understanding. Assuming I managed to convince you that clean code is more than a fad. What does clean code looks like? Robert C. Martin wrote the book "Clean Code" in 2008. Clean Code might very well be the best definition we currently have. I encourage you to forget about the cargo cult that wraps this topic (and the distasteful choices R. Martin took in the last years) and read the book. Spoiler alert: Clean Code's main message is readability. In Robert Martin's own words:
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.
The ratio of code read versus written is disproportionate. So disproportionate that we should do everything that is in our power to ease the reading. And so even if it makes the writing much harder. Robert Martin advocates for example the use of intention-revealing, pronounceable and searchable names. He says we should strive for small, single responsibility, single abstraction methods. We should pay attention to comments as they may be hints that the code itself lacks readability.
Robert Martin was the one to introduce the concept of "boy scout rule" in the software world. He reused in his own terms a quote of Robert Stephenson Smyth Baden-Powell, the father of scouting:
Try and leave the code a little better than you found it. *
Writing clean code comes at a price but the benefits are endless.
But writing Clean Code isn‘t the end of it. To make things right, you must work at the meta level too. If you can improve the kitchen itself and thus your cooking „flow“, refactor it. Bring the spices closer to the stove and the bread farther from the oven. Separate components that have different responsibilities. Bring together objects that depend on one another.
There is nothing wrong with making a decision and building things one way. As long as you are able to look at it and learn from it afterwards.
Remember, “make it work“ before you „make it right“. But don‘t forget to make it right afterwards. Otherwise, as James W. Grenning puts it:
„Your app only passes the App-titude Test, it works but it‘s aweful“
* The original quote from Robert Stephenson Smyth Baden-Powell: "Try and leave the world a little better than you found it"
Photo by Jon Tyson on Unsplash
Read the two other parts of this series: "Make it work, Make it right, Make it fast" (Kent Beck)
