“Code as if the one who will inherit your code base is a psychopathic mass murderer who knows your home address.”
— Anonymous
“Code as if the one who will inherit your code base is a gossip who has lots of gossip friends.”
— Anonymous
Maybe you are familiar with these kinds of programming jokes.
If we give time to think more on these jokes, we will start to realize that it seems like the authors of the jokes are programmers themselves; and it seems like they are trying to instill fear in the hearts of programmers! 
(Including themselves, perhaps?)
Wow!
It seems like they want us to be conscientious when we code.
They want us to think of other people, our coleagues, when we code.
They want us to think of those future programmers who will inherit our code base.
“Will our coleagues, and the future programmers, be able to understand our code?…“
You see, we, programmers, most especially those who already have years of experience coding, have this secret fear — the fear of becoming slaves of our software creations.
The fear that we will be controlled by our software instead of us controlling our software.
We often experience this controlled-by-software thing during bug fixing.
After reading a bug report… “fifteen minutes! I’m going to fix this in fifteen minutes!”
Then an hour passed, it is still not fixed.
… Four hours later …
That is an example of software controlling our lives.
We want to get rid of that kind of experience.
We want to get rid of that fear.
What could we possibly do to make that fear go away?
“You give me an application that is beautifully designed but there’s no tests. I’ll be afraid to touch it. It will rot.
You give me an application that is badly designed but has a comprehensive suite of tests. I can make the design better because I have a suite of tests.
A suite of tests is more important than a good design.”
— Uncle Bob Martin
“Code without tests is bad code.
It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is.
With tests, we can change the behavior of our code quickly and verifiably.
Without them, we really don’t know if our code is getting better or worse.”
— Michael Feathers
So… a comprehensive suite of tests will make that fear go away!
What could possibly make us write a comprehensive suite of tests?
PS:
Just in case you fear that the “gossip joke” above will leak from the joke world to the real world…
there already exists practices that can prevent that from happening:
“Pair Programming” or “Mob Programming”
…
I asked: “Jerry, do you do this with your own code too?”
Jerry scowled: “We work as a team around here, so there is no code I call my own.
Do you consider this code yours now?”
“Not anymore.” I said, meekly. “You’ve had a big influence on it.”
“We both have.” he said, “And that’s the way that Mr. C likes it. He doesn’t want any single person owning code…”
— from “The Craftsman #3: Clarity and Collaboration” of Uncle Bob Martin
Many consultants believe that pair programming is the universal solution to any problem that a software project can have.
- It spreads the technical skills
- It spreads the functional knowledge
- It builds the team
- It’s fun
— Victor Rentea, “Brainstorming a Clean, Pragmatic Architecture”
