Imagine for a moment, that you have been handed a project that was done by somebody else? You look at it, and maybe the whole thing isn’t perfect *ehem*. I’m sure you’ve seen this before. Nearly every program that you will ever see, has some room for improvement. Some more and some less.
If you are an experienced programmer, you probably already know the answer to this problem. There are some things that can (and probably should) be done to improve the quality of nearly any project: At a minimum: put it through a peer review. Right? Oh, but then you start to think “I could just review my own stuff. I don’t need a peer”. Look, you already had time to do that and how far did that get you? Step 1 is acknowledging that there is a problem. Now, go find a peer.
In contrast, most programmers, if left un-checked, will tend to feel more accountable to a timeline than their successor. After all, how many times have you had a boss / supervisor / PM, bug you about “Why isn’t it done yet?!” Now, imagine if you told your PM, “Hey, take a seat! I’m trying to determine the most eloquent way of refactoring this code, so the next person is impressed by my attention to detail and overall quality.” I’m sure your PM will immediately recognize the higher value of this and he will quickly deliver a heart-felt apology and tell you to take your time. (in your dreams). And so, we usually feel pressure to get stuff done, rather than getting stuff done-right.
Several months ago, I was talking about this same topic with a colleague of mine. I was trying to persuade him to have his project designs reviewed by a peer. Unfortunately, he seemed to think that I was trying to criticize him, rather than offering support and encouragement to maintain high standards. I know he was just trying to keep his boss happy. After all, his manager wanted this work done quickly and was not requiring any kind of review. So, why expend the extra effort?
This wasn’t the first time I’ve had a discussion like this, and I’m sure it won’t be the last. Each time I bring up the subject, the other person seems to think I am being rude or bossy. Maybe I think I’m everyone’s mom, and I’m digging into their business because I have control issues or something. Well, I don’t. I just expect people to help their peers by raising-the-bar. So, I honestly expect that my colleagues will seek some kind of review, from someone other than himself.
The point is that, it doesn’t matter what I think; What matters is this: deliver the best project that you can. If your stuff is good (or great), other developers should be able to review your designs and code and agree the design is good. If they disagree, you should be able to convince them, based-on the merits of the project (not on your own merits).
Oh, and if you think your design is so great, or you are so great, that you will not be able to find a peer, or your colleagues will not be able to understand your design, then you need to get a grip. Your design should be understand-able to any programmer. We aren’t inventing time-travel or anti-gravity here folks. If your designs are too complex, then you probably should have picked a simpler design in the first place.
For more information, please read my article about “egoless programming“.