Let Someone Walkthrough Your Unfinished Code

When I last year read Adam Tornhill’s great Software Desing X-Rays (my blog post about it), there was one hint that surprised me totally:

I recommend that you do your initial code walkthrough much earlier. Instead of waiting for the completion of a feature, make it a practice to present and discuss each implementation at one-third completion. (Adam Tornhill, Software Desing X-Rays)

The idea behind this is that usually when the code comes to review, it is too late to make significant changes to it. But if someone reviews my code while it is still under construction, I still can make changes to it. There isn’t yet need to be too busy to improve.

Example: Urgent and Big Code Review Just Before The Deadline

Maybe many of us have got a code review that is urgent: “This must be accepted/merged in an hour. Our code ships then.”. And when we look at the code we can say only “This is horrible code, I can’t let it pass the review!”. Then the manager forces us to accept it and promises that this was the last time we have to pass this kind of code, no matter how urgent it is. This shouldn’t happen but we know it happens now and then.

That has happened to me also. This is the situation that Tornhill describes: it is too late to change the code (“It works?? We don’t have time for better code: deploy it!”). But think if that code was already walkthrough when it wasn’t ready yet? A reviewer could’ve mentioned about problems earlier and a programmer would’ve fixed them in time, early enough (and with much less WTF’s).

Focus on New Files

Most of the smell instances (at least half of them) are introduced when a code entity is added to the versioning system. (Michele Tufano et. al., When and Why Your Code Starts to Smell Bad)

That is a surprising and interesting finding from Michele Tufano et. al. in their research. Usually, we think that code turns slightly into spaghetti, and that is also true. But in most cases, it is the first version that is already “bad code”. By letting someone to look at our code much earlier than we think it is ready, we can make our code better in the first place. That would improve code quality, and there will be less spaghetti code.

Need of Mental Strength to Show Weakness

It is not easy for everyone to show their unfinished code to someone. I have to admit that I wouldn’t enjoy if my colleagues read my code that isn’t finalized. I want some “privacy” during coding (That is why I’m little afraid of pair programming even if I fully understand its strength). We can’t be afraid of mistakes, and in this context, mistakes are really cheap! The code isn’t even yet merged to master branch so there isn’t need for panic; we can still fix it.

Isn’t this same as traditional code review? Yes, kind of; we just review code more often and smaller sections at a time. Sounds like clean code: small is beautiful. Next time when I’m coding, I will try to give my one-third completed code for review.

Sources

• Software Design X-Rays by Adam Tornhill. Chapter 10,
  An Extra Team Member: Predictive and Proactive Analyses.
• When and Why Your Code Starts to Smell Bad by Michele Tufano et. al.