So you think that new module of code that you just whipped up is just fine? You even wrote it with a pair or two! All of the names are the best that you could think of, the thesaurus is still smoking as it sits next to your keyboard. Control flow effortlessly flows from one expression to the next. Data dances in happiness for the structures that you have decided to use. This is not in any way going to be a maintenance problem!
Are you sure? Have you tested it? No, not that kind of testing. I trust that you have a good set of unit tests. Maybe even some nice acceptance tests that were looked at, or provided, by your stakeholder. No, what I mean is have you tested that it won’t be a maintenance problem?
Sure, sure. It was written with pair programming. You swapped pairs several times a day. You probably even stepped away from the keyboard for a bit, went to a whiteboard and hashed out what you were going to build. You communicated this to the team and you all knuckled down and gave it your darnedest. But did you check that someone else can understand it?
What? Someone else? What do I think all of this pairing is about! All of this whiteboard writing. All of these acceptance test shenanigans!
The problem is that your entire team might have succumbed to groupthink. Every one of you got on the same page and stayed there. You might have become blind to something that you think is obvious, but is completely unintelligible to someone outside the group. So let’s do a little test and show that code to someone who has not seen it before. Let them be the judge of how good it is.
Now I’m not saying that you should be doing a sit down formal code review. Think of it as a simple form of usability testing. Grab another programmer that is familiar with the domain and sit her down in front of the code. Ask her to perform some actions on the code and to answer some questions about it. You might try:
- How does this code achieve foo?
- You need to add functionality bar. Show me what will need to change.
- When I perform action baz in the application why does it respond with blub?
Watch how your subject interacts with the code. Watch her fumble and second guess her understanding. See the ease with which she performs some actions and has trouble on others. Now take that information and try to improve your code!
Something that you really need to remember when doing something like this: you are not testing your colleague! Any failings that the test uncovers are not because she is “stupid” or “doesn’t understand,” they are because the code you wrote wasn’t fully up to the task at hand. Having that pointed out can be hard to deal with, but it is there in the data. Now it is up to you to improve and figure out how to fix the problems. Good luck!