Stop Asking Permission To Do The Right Thing

I was originally going to title this post “A Business Case for Unit Testing”. I was going to talk about how it helps you to find bugs early, spend less time debugging, and all the other benefits I have mentioned in my previous posts. I intended it as a cheat sheet to help developers make a case to their boss about why they should be doing unit testing. I envisioned employees either sending a link to their boss or using it as talking points in discussion with their boss. Then I realized I was approaching the situation all wrong.

The Maintainable Podcast

I stumbled upon a podcast called “Maintainable” through a tweet. They were advertising an interview with Micheal Feathers, author of “Working Effectively with Legacy Code”. I was intrigued, so I listened to it. It is an amazing podcast series that I would recommend to anyone involved with producing software.

I had my epiphany when I went back and listened to the first episode. The host, Robby, is interviewing Anna Filina. About 25 minutes in they have a discussion about developers feeling like they had to ask permission to do things like unit testing and refactoring. Filina’s answer was to not ask permission but simply just start doing them. You should all go listen to that exchange. I think it is quite eye-opening.

It gets deeper

It’s more than just simply not asking permission. It has to do with changing the way we think about writing code. If we view refactoring and testing as ancillary activities then it is easy to feel like we have to ask permission, because we see ourselves as taking on all this extra work. However, if we view these things as an integral part of writing code then there really is nothing to ask permission for. Our job is to write code and that simply entails refactoring and testing just like it includes using source code control.

Stop treating refactoring and unit testing as separate activities. They are integral to writing code.

Here is an example that most LabVIEW programmers can identify with. Imagine you inherit some code and it is a state machine with say 20 states. It has no documentation. Your boss says he wants you to add some feature. Where do you start? If you are like me, you start by getting a pen and paper (or whiteboard) and going through each case and drawing out a state diagram, so that you can understand what is going on. Your boss didn’t explicitly ask you to draw a statechart. Do you stop and ask permission to do that? Of course not. It is simply part of the job. We need to start treating refactoring and unit testing the same way.

Now you might be skeptical and say “Ok Sam. That is great, but isn’t writing all these tests and doing all this refactoring going to take more time? My boss is going to notice my productivity falling.” If that’s you, then you need to follow the link below and watch Gee Paw Hill’s video where he thoroughly debunks that myth in less than 10 minutes.