In my 15 year career, I have yet to encounter a software company in Slovenia, where code review would be a part of work process. It is surprising how many companies just don’t care what kind of code they produce. And this is exactly the reason why most software originating from Slovenia, well, sucks.

 

The funniest thing is, though, that doing code review is simple. You invite fellow co-workers to a meeting, put your code up and say: “This is what this code does. What do you think?”

Yet, every time I pressed this topic in a team meeting in any of my gigs, I got the same response: “Why do you need that for? We don’t have time for this.”

I don’t think this argument holds water. First of all, bad habits have a habit to grow exponentially. Bad code breeds only more bad code. Secondly, adding a new feature or fixing a bug when code is crap takes a lot longer than doing it in code that everyone can read and understand.

Let me tell you a little story. When I was still working part-time as a student at my previous gig, some co-worker was given a task to implement shopping cart. Now, in those days XML was the latest and greatest technology and said co-worker decided to use this technique to implement shopping cart. However, unlike today, browsers then had a small issue of not supporting XML transformations or XSLTs. So did Domino server. To overcome this, server code was put in role of XML to HTML translation without XSLT. It was written entirely in LotusScript. The cart shipped and all was well and the guy left. So, the honor of maintaining this wonderful piece of software was befallen on me. I needed about a month to actually comprehend what code does and how it does what it does. The code was all over the place to say the least. However, even seeing how bad code was didn’t stop me from continuing the pattern. No, it actually gave me justification to continue in the same direction and produce more bad code. Code review would stop me (and original author) from doing that. Plus it would save me at least three weeks of time when I was getting to know the code.

The thing is, that information obtained, questions asked (and answered) and knowledge that gets shared in a code review are priceless, they improve every ones code, make software easy to maintain and prevent people from obtaining bad habits like naming a variable “foo”.

So this got me thinking. Why don’t developers do code review? The only reason I could think of is that they are afraid they are going to get ridiculed. Trust me, nobody will. Everyone knows how it is to be on the receiving end. Thus, you will have more trouble convincing people to tell you what they think. So stop seeking excuses and just do it!