Let me explain.
Perhaps you’ve been in a situation where you’ve been unsure whether it’s okay to spend time writing tests for the feature you are implementing. Asking your manager if you should write tests seems reasonable.
Perhaps you’ve felt guilty about how slowly software development is progressing, or your manager clearly stated that writing tests only wastes time.
But asking your manager for permission to write tests is like asking them if you can go to the restroom.
When you need to poo, you go to the toilet, and you’re most likely not going to ask for permission, right?
Imagine what would happen if your manager said “No!” when you asked them if it would be ok to go to the restroom.Â
At first, you will be fine.
After a while, you start to feel uncomfortable. You are distracted because you need to focus more and more on holding it in, and your performance goes down.
Finally, you cannot hold it anymore, and you shit your pants. 💩 Your colleagues start to smell it and complain about you.
Now, you must stop your feature work and clean up the mess.
Now, imagine what happens if you skip writing tests.
At first, you will be fine.
After a while, you start to feel uncomfortable. You are distracted because you need to focus more and more on understanding this complicated code, and your performance decreases.
Over time, the codebase becomes so messy that you don’t notice that you broke something. 💩 Your end-users start to complain about bugs.
After a while, there are so many bugs to fix that there’s hardly any time left to work on new features.
Eventually, working in the codebase becomes so painful that you and your colleagues wish they could stop feature work for a few weeks to clean up the mess. But your manager is undoubtedly not going to approve that.
Asking your manager if writing tests is ok is like asking them if you can go to the restroom. It’s not their decision to make!
The problem is that managers often cannot judge whether writing tests now is a good idea. Your manager might not see the direct and indirect benefits, so they conclude that writing tests is an additional effort that can be saved for other activities—for instance, implementing more features.
But you are the expert. You are a software engineer who knows the benefits of practicing Test-driven Development and why writing tests is the only reasonable option. You know that not continuously writing tests will come to you and bite you in the ass eventually.
Using a Test-driven approach has many other benefits besides creating a safety net that prevents bugs from entering the final product. Small steps and the incremental nature of TDD, for instance, make you think harder about the problem, and the solution will be more sound. Also, continuous refactoring is built into the process of Test-first Programming, and your code base will be much cleaner and easier to work with going forward.
What are your thoughts on my 💩 comparison? Send me a message and let me know – I read all emails!
See you around,
David
P.S. Did you enjoy reading this article? Then don’t miss the next one – consider signing up for my newsletter.