Bad code, we all do it.
Bad code we all do it.
Well, I had written my share of bad code. Couple of weeks ago I had to fix up a class that was written about 4 years ago. For a while I could not believe I wrote this, but the comments on top clearly identified me as a suspect. The thing is we all write bad code sometimes. If you never wrote any bad code, please raise the hand with which you did not do it.
So, going back to the story – I was looking at it and my first impulse was to try to hide it far away so nobody would ever have to look at it. My second impulse was to rewrite it. I figured, it would probably take me about 5 hours to redo this. I did not do any of it. Instead I brewed a fresh pot of coffee, put my pride far away, printed out copies of it for all developers in the office and decided to play a game. My team consists of 4 coders; two of them were with the company for about 3 years, 1 for about a year and one guy just started in September. So instead of hiding it or quietly rewriting it, I gave my guys the printout and asked them to find mistakes in the class. By the way, the comments that contained the name of the author were not printed.
“Who wrote this crap?” this was the first thing I heard. Then in a typical spirit of our development team there were suggestions on what should be done to the author. And finally there were suggestions, many suggestions. Some of those were good, some were pointless and some were plainly wrong but one thing stood out for me – we all came up with different things to solve the same problem. At the end the class was rewritten and suggestions from the rest of the team were used. After it was done, there was a noticeable performance improvement. Let’s say file X would take Y seconds to run through the original class, after the changes the same file X would take Y/3 seconds. I am talking approximate timing, never actually forced any performance testing. Oh yeah, at the end of it I told everyone who was the author. That did create some awkward silence for a minute or two.
Why did I do it – I was quite capable of doing the work myself. As a team lead, it might be a good idea to hide my own faulty code to keep my image, but instead I did the opposite. I choose to do this for several reasons:
- We are all stressed out, the project we are on. We all needed a break from it. This injection of new problem did wonders for the main project.
- I don’t really care about my image, in fact, I would prefer them not to think that I am incapable of making mistakes and can’t be considered a final authority. I wanted them to find their own solutions.
- We all contributed and the result was truly a collaborative effort.
- It was clear that we all have different approaches to the same solution.
The whole experience was good. Bad code is unavoidable, but if you learn from it, it was not just a bad code it was a learning experience.
