Doing this one thing will dramatically improve your code!
I know what you’re thinking…I sound like an Informercial salesman! I promise that if you stick with this article it will be worth your while.
In order to deliver on my promise, I want to tell a story. I was assigned to work on a project with a very short deadline, understaffed and a list of features that would have to be squeezed into a VERY long scroll. I know this is not only a cliche, but the status quo for Developers. I ask that you hear me out. I worked feverishly on this project, putting in overtime and constantly stressing about it even when I was not at work.
What was supposed to be a couple of months turned into four months. It wasn’t THAT the project went over its allotted budget but WHY it went over its budget that was interesting to me. We had all of the features in by the two month mark. It was the BUGS that were eating up most of our time! The root cause of this wasn’t that our features were difficult to implement, it was that our code changes would break other features of the app. At this point it would be easy to point out that our app lacked structure. Although we did use an MVC framework, there were parts of our code that were messy. You could make the argument that we weren’t using Source Control. We were. We had multiple people managing our repo.
What we lacked was rather simple…we lacked Automated Testing!
Heresy! That’s right, we didn’t have any Unit Testing, or Integration Testing or Functional Testing. It was purely code and pray. And it cost us to say the least. It was a painful lesson for me. I don’t pretend to be a Kent Beck or an Uncle Bob, but after this project I bought ALL of their books and devoured them over the course of a week.
For me, that project was a tipping point. For a long time, I dabbled in Automated Testing. I kept hearing whispers about it. I heard that it was something “Real Coders” used to produce high-quality code, but because it wasn’t a strict requirement at that company, I was lazy about using it. I would get “spasms” where I would try to use it for everything, but then I would get frustrated and give up.
When I was finished with that project, I became 110% dedicated to using and mastering the technique of Test Driven Development. Sure, there were times where it did take me longer to complete a task, but the confidence I felt in my code was well worth it. It certainly didn’t catch all of the bugs I produced, but it decreased the amount of “stupid” bugs many fold. I define “stupid” bugs as passing in the wrong type of arguments to a Constructor as an example.
It was this project that I am most thankful for in my career. Not because it was glamorous, or made me “Internet famous” or anything like that. It’s because it took this vague pain that I felt on a lot of previous projects and really made it visceral. It forced action to improve and it thrusted me out of my complacency and into a new realm of professionalism and well-crafted code.
If I ever meet the Authors of these books, I will thank them profusely for the impact they have made in my Career and my Life. These books are:
Working Effectively with Legacy Code
