or The art of using Baby Steps and other strange programming principles
Over the years writing code, I have been testing various programming principles. Some I rejected, others I adopted and others I adapted. I also invented some.
It is not enough for a principle to be very good, it needs to be remembered or it will not be used. I believe that the most remembered principles are those that are imported from the everyday life. And if they are associated with something nice or have a funny name, more we tend to use them. And lighter our work becomes.
The Chuck Berry principle
This principle is also known as the Too Much Monkey Business principle.
Sometimes you have the strong feeling that the path in front of you has unnecessary complexities. That the time and effort you have to spend learning and using something will not be rewarded. Be it a framework, a programming language or just a design pattern.
Sometimes it is not easy to keep the straight path. The misleading dark forces are very powerful. They cast The Hype on you.
Don’t despair. Don’t lose your faith. Start singing.
“Uh-uh, too much monkey business,
too much monkey business
Too much monkey business
for me to be involved in — Oh-ho-ho”
The Simple Complex System principle
How to write complex software? Don’t start writing code before you achieve a clear and simple conception of the complex system (application).
You must understand a complex system as an unequivocal relationship among unequivocal components.
By “unequivocal” I mean obvious, reliable, intuitive, efficient, correct. Something that ANYONE easily understands and agrees. Something impossible to be misunderstood.
If the components have no flaw and the relations among them have no flaw, then the system has no flaw.
A subsystem is any system that also is a component of a larger system.
The When Not Wet, Don’t DRY principle
This principle is the countermeasure against the famous DRY principle.
“DRY” is the smart acronym for “Don’t Repeat Yourself”. DRY is about avoid redundancy. Has a very pop name, makes sense at start, and very often is a disaster to your code!
I’ve been harming my code and wasting my time hundreds of times, trying to please the DRY gods. Hoping that they would help me feel less incorrect as programmer.
Don’t go “Oh my Goodness!!! This function that I am writing is so similar to that other perfect and tested function from the other module… I must merge both. Or else I will be repeating myself!”.
Friend! Do me a favor: leave that PERFECT, TESTED function in peace!
I wish someone had taught me this a long time ago:
The DRY principle is about the architecture. Not about every small function.
“Don’t repeat yourself” is a misleading phrase. Everybody takes that as “Don’t repeat your code”.
In fact the DRY gods don’t care about mundane copy and paste. Because… they are gods and not your school teacher examining your home work. Their concern is all about roles (don’t repeat functionality).
If it is not wet, don’t DRY it!
The Automotive Metaphor principle
Imagine you are driving a car. Do you want to turn the car? There is a specific component with the specific role of be the interface between the wheels and the user: the steering wheel. Which has a simple, intuitive way to be used: spin it clockwise and the car turns right. Spin it counter-clockwise and the car turns left.
Do you want to speed up the car? There is another specific component with the specific role of accelerating the car, being the interface between the user and the engine. Guess its name? “accelerator” — unequivocal name! And it is completely independent of the steering wheel. You can spin the steering wheel and press the accelerator pedal at the same time.
Car manufacturers always wanted to sell as many units as they could produce. And they know they would sell too less cars if, in order to be used, cars require
- highly specialized knowledge
- a shift of the user’s mindset
Therefore, the easy using of your car is on purpose, concerning profit and safety (a car that is difficult to master is an accident-prone car).
I fear the day when some programming language designers start to prototype a car.
“Make a car easy to be mastered by the user!” — when was the very first time an engineer heard this advice? I believe that it was circa 3,500 B.C., 15 minutes before the humanity invented the wheel. That’s why modern cars run without bugs: they had a lot, I mean a LOT, of alpha releases in the past.
A car is an excellent metaphor for the architecture of your application. And you should care about the users of your code like you were a car manufacturer. And the main user of your code is you tomorrow.
The Clever Oscar principle
“I am so clever that sometimes I don’t understand a single word of what I am saying.” — Oscar Wilde
The followers of this principle use to write code in a manner so obvious that even a fresh student can understand. They believe that cleverness, sophistication and implicit design are the root of all evil.
They practice self-documented code. Which means that the structure of code and the names of modules, variables and functions must clearly express their roles. They consider heavy use of remarks as an awkward technique. And unsafe because often people forget to update them.
Their ultimate aspiration in life is reach Zero Guessing Time when reading their own code in future.
Create an architecture so obvious, intuitive that people will know how the code works before read the functions.
The Radical Uniformity principle (REJECTED)
This principle advocates that having absolute symmetry and uniformity in code is your highest priority. If you follow this stupid principle you will be always refactoring your whole code to make it match some nonsense criteria like all your files having the same number of lines.
This principle is here just to tell what you MUST NOT do.
This principle was invented by me. Then, after a decade of suffering and consecutive failures, I was smart enough (I am so proud!) to drop this principle in favour of the next one.
The Vive La Différence principle
I adopted this principle hoping it could heal me from the Radical Uniformity principle. I can tell that the treatment was successful, although not easy or fast.
The followers of the Vive La Différence principle have a robust emotional structure and don’t see problem on having a “switch” statement in one function while all the other functions only use the “if-else” statement.
According to this wise principle:
Elements of your code are NOT soldiers in a military parade.
The Respect The Elders principle
“Elder” means that old code that you may find to be obsolete or difficult to read, but which has been reliable for a long time and… is still running!
This principle warns you to never underestimate the value of a tested, reliable code, does not matter how ugly it may look.
If you wish to renew it. Create another one from scratch. Don’t mess with the elders.
The Roman Emperor principle
This principle states that you, in your own right, are the lord of your code. That your code should be under your COMPLETE DOMAIN. If there is some module or function resisting your domain you must draw your sword and smash the rebellion (refactor the code).
As a true roman emperor you would never accept run a code that you could not edit or understand. Therefore you ignore the obtuse commoner yelling “If it ain’t broke, don’t fix it”. You break it with the sword, then you fix it!!
The Henry Ford Doppelgänger principle
Software architecture is too much abstract. You can do anything (good or stupid). This principle states that you should think on a concrete successful model to guide the architecture of your application. Always ask yourself what would you decide if you were Henry Ford.
Before Henry Ford, the process in the car factories was this: the car stands still while teams come to work on it; many teams, same place, a mess.
Henry Ford reversed the process: each team takes its own place and the car passes by them. Each team (role, functionality) has its own exclusive place (directories, files). And the communication among teams now is very low. A team waits the car to come, executes its process and sends the car forwards.
The internal structure of each team (module) was the standard “manager plus workers”.
The manager (a kind of function) coordinates the workers and communicate with other teams. The manager does not executes the process on the car.
The workers (other kind of function) only communicate with the manager. And they execute the process in the car without thinking or knowing anything about the rest of the factory.
The Sherlock Holmes principle
This principle tells you how to identify the culprit (bug) of a crime:
Just use basic deduction and follow the timeline backwards.
Imagine that your application is OK. You edit the module Z and your application starts doing strange things (like crashing, for example). You think “The problem cannot be with module Z. There is no possible relationship between module Z and this problem.”. Then you start reading all modules from A (except Z, of course). You don’t find the bug. Then you start editing all modules (except Z, of course) trying to isolate the bug by chance. As you edit tested and perfect modules, there is a chance you create bugs…
Adopt Snoopy Holmes as your mascot and you will never suffer this way again!
The Mad Scientist principle
The Mad Scientist principle focus when you’re going crazy because things just aren’t working as they should; no matter how many times you’ve checked and edited the code. There are 3 scenarios:
A) Problem: Your code is not running according to your expectations. Solution: Your code is all right. Your expectations are wrong.
B) Problem: You constructed a simple tool to test your program. The tests say your program is not OK but you can’t find the problem. Solution: Your code is all right. Your tool has defect.
C) Problem: Your program simply does not change its behaviour, no matter how much aggressive are the editions. Solution: You are editing one version and running other.
Bonus for Linux desktop users:
1) on terminal type mkdir mad
2) on terminal type cd mad
3) on terminal type touch damn
4) on terminal type ls # shows damn
5) on GUI rename mad to mad2
6) on GUI create a directory mad # empty
7) on terminal type ls # shows damn!!!
The Baby Steps principle
Don’t take a baby step as a fragile step. A baby step means a small step walked in the right direction and in the right time. Therefore, go baby step after baby step and you will have the job done. It sounds like the definition of algorithm, doesn’t it?.
In addition, each small step is a small victory, which increases your self-confidence and enthusiasm.
A baby step is a well thought out movement, decided without haste, in clear state of mind. It is simple and safe by its very nature. It is not a giant step that intends to do many things at the same time. It is a humble step. Not a vain one. It is reliable. It is a “do it once and do it well” kind of step. You don’t want to send the baby back to the starting line.
You may consider the Baby Steps principle as the core concept underlying all the other principles in this article. And of some good principles outside.
By using the Baby Steps principle, you automatically apply the Premature Optimization Is The Root Of All Evil principle. Because obviously a baby step is not a premature step.
You also apply the YAGNI — You Ain’t Gonna Need It principle. Including code that the application does not need to run messes the architecture. Your architecture is not obvious anymore. Have you ever heard of a car engine that has a component that does nothing?
Imagine that one day you are confused and stuck because there are so many ways to start your work. How would the Baby Steps principle help you? Do this:
1) put all options clearly on the table
2) select the steps that are common to to all options
3) execute the selected steps that you can do right now
It seems magical how you become productive immediately.
Now, suppose you are in the “I don’t have what it takes.” mood. What the Baby Steps principle would say? It would say “use what you have at hand”. Give a small step ahead and things around you will turn different. This is a special case where maybe you will have to refactor everything later because you are in the experimental/learning mode. Anyway, clearly the Baby Steps Principle is helping you to advance.
If you are not convinced, think about the creators of the computer. Do you imagine they giving up because “Oh no! This hardware is useless. Each bit of its memory can store only 2 values (0 and 1). And I need to store the whole alphabet, punctuation symbols and digits from 0 to 9 inside a character.”? Instead of giving up they created machines that do wonderful things based on a very long sequence of ridiculously small steps!
The Perfect Application principle
A perfect application is any application which code is easily maintainable and that runs exactly as planned. Be it trivial or spectacular.
All other principles here are the means to create a perfect application.
What about Bob?
What about Bob? was a successful comedy film released in 1991. It was starred by Bill Murray as Bob (a very neurotic patient) and Richard Dreyfuss as Dr. Leo Marvin (his therapist).
The plot: Dr. Leo Marvin is in auge of his career because of the innovative Baby Steps treatment he developed to help nervous people cope with the small adversities of everyday life. And… well, I don’t want to spoil the movie for you. I recommend watching it.
For years after watching the movie, sometimes, just for fun, I have imagined Bob using Baby Steps principle in situations I was living or were happening near me. And I realized that the principle works!
So I adopted it seriously for the everyday cases. And then I started using this principle in code. Only eventually at beginning. And after more and more.
Many times I said to my self “I wasted many hours AGAIN just because I am stubborn and lazy and did not use Baby Steps, as I promised.” . It is one of the few principles that I really call by name.
I fear that someday Dr. Leo Marvin sends me a bill.