In my opinion, the process of reviewing code constantly lags behind the tools used. Beginning as a consultant at Ericsson in 2004, it was still custom reviewing the code in the end of the development (waterfall model) during a revise meeting. The code was printed and everyone made notes, whereupon around 10 employees gathered to review the code together. The problem with this process is that the code was already implemented, consequently the time to carry out alterations was scarce. Furthermore, the person reviewed had worked with the code for several months, and in case of structural faults more than half of the work could have been a waste of effort. No matter what, the product had to be delivered, hence usually only minor changes were done.
The age of the punch cards
The reason for conducting code review in this way has often crossed my mind. Where does this process originate from? I remember my summer practices at Kockums Computer Systems, and later my first programming course at LTH in 1982. Individual computers was not a reality back then, and there were still to few terminals to enable all new students to connect to the existing server by these. The other day I found a batch of punch cards with our programming assignment. Even though it has been almost 35 years, I still remember the procedure. First, an outline of the program was made with paper and pen. Second, different solutions were discussed with the classmates. Then a time was scheduled in the punch room, accommodating a number of keypunches, big as a large-sized desk. The programming code was entered row by row. It was important not to drop the punch cards so that you had to put them back in the right order.
Speaking of punch cards, I recall a specific room at Kockums, where about 20 employees were creating punch cards. These probably contained data of salaries etc, eventually entered into a computer to place orders with the bank and stored at tapes. Once a week I was responsible for delivering these tapes to SEB.
After punching all the cards, each consisting of one row, it was time to run them. While former students had to submit the batch of cards to the data processing centre, to run the program nighttime and then fetch the paper based result the next day, we were lucky being able to place them in the card reader and start it on our own.
I am quite convinced that Ericsson’s code review procedure was a remnant from the ones developed during the 70s, reflecting completely different opportunities than today’s. If I was unlucky running my batch of punch cards, the compiler disapproved due to a syntax error. I then had to book some additional minutes by a keypunch to create one or several new punch cards.
Under those circumstances, it was natural asking classmates for help with reviewing the paper based code, and also check the finished punch cards. However, the projects didn’t last for months, on the contrary there was a limited amount of code to review. Batches of punch cards containing more than a couple of 100 rows of code were quite unwieldy. In other words, the waterfall model worked well since the code rarely was written for more than a couple of weeks.
Gerrit and other tools
As a reaction from the developers, tools like Gerrit and Code Collaborator were eventually released. Instead of printing the code and holding meetings, the review take place in the computer. Moreover, it was easier to notice alterations since the last review. In the beginning these tools allowed the review to be made similarly to the “punch card method”. The review is distributed, the reviewers comment, the responsible programmer upgrade the code and finally the review is revised. Since then, Gerrit has taken a step forward, now allowing both the reviewers and the responsible programmer to edit the code directly in Gerrit. Thus, minor adjustments and be added both directly and as a proposal, which can be confirmed without making a new round. Generally this should decrease the process and save time.
Being able to edit in the review is in reality a step towards pair programming, which actually existed before Gerrit was introduced. In pair programming the code is continuously reviewed by the non driving individual, the so called observer. Sometimes this is regarded as a waste of time, but in an analysis of the total time consumption during the traditional way of programming, I personally find indications that pair programming takes less time. Two alternative scenarios can be considered; either no code review at all is accomplished, or the code review is done when the whole product is finished according to the developer. “The whole product” can be everything from a couple of rows to significantly more, nevertheless I personally find the reasoning suitable for both cases.
In case no code review is done, the process more quickly moves on from code to integration tests. The subsequent situation depends on the experience of the programmer etc, but the risk of detecting errors later in the process is clearly bigger. All these errors must be identified, followed up, corrected, tested etc. Of course the time saved when neglecting pair programming can quickly be wasted at this stage. If it comes to the worst, severe errors can be delivered to the clients, not to mention that the code more or less has to be rewritten since the requirements have been misunderstood, or the design is not compatible etc.
In case the code review is done at the end of the process, a lot of time is spent on administering the review. First the reviewers have to familiarize themselves with the requirements, comprehend the design and then evaluate and understand the code. Further these ideas are communicated by text to the responsible programmer who has to interpret them and decide what must be done. Perhaps the programmer can’t really understand and summons to a meeting, or adjustments are done which must be iterated one more time. From my point of view these iterations usually takes time. On top of that, employees involved must do the review and alterations in between other assignments. It takes time and energy when you must change focus and recall where you were. In pair programming, on the other hand, there is complete focus at one task at a time.
Pair Programming 2.0
An “online pair programming”, where the whole team continually are able to monitor each other’s code, and any editor can be used for updating. With one keyboard each, both programmers can run at all times. Preferably, this should take place in the same hall, but with the video conference tools of today, distance programming should be possible aswell. Basically, pair programming, however everyone can write simultaneously. Under those circumstances, it seems to me that the pair programming can obtain a better flow. With the observer adjusting the code, the driver can stay focused and won’t have to modify every single error in the previously written code.
So what is the next step?
How do you believe this will work out? What is the next step in the technical evolution, forcing us to reconsider the process of developing code? Utilizing the Waterfall Model in the 60s is completely understandable. According to me, the problem is how the processes of the corporations doesn’t keep up with the technical development. The absence of a semicolon during the times of punch cards caused a significant delay with my task. Today, existing editors assists in adding these components, and the code is continuously compiled to eliminate syntax errors. Obviously the processes must change with the prerequisites, but how will this take place in the future?
Don’t forget to adjust your processes according to the utilized tools and analyze every step of your work, to see what it might bring.