“People and Code” — Part 1 — Reviews
Over a number of years in the software industry I have experienced changes to how we work together as people, the tools that change our collaboration options and the code itself.
I have worked for the majority of this time in a number of different development teams as a developer and more recently changed to a new role, which is focused on the people and how to help them identify and grow in both core and technical capabilities.
Development Methodology has changed in the majority of cases from Waterfall to more Agile Methods including SCRUM, Kanban and XP (Extreme Programming).
When you compare these methods at a high level the main change is an increased emphasis on People — How people on the development team interact Together, with the Customer and the Code.
In my new role, and with my interest peaked by industry thinkers like Adam Tornhill, the area of human psychology and code is something I have been thinking about a lot more.
In the first part of this potential mini-series of blogs I want to look at the subject of Reviews. How have they evolved in relation to the changes in methodology and tools and leave you with some questions to consider if your review process has truly evolved as far as it should.
In my first industry experience of “The Code Review” in the mid-2000s we were firmly working in a Waterfall method of development on a split location team.
I spent several days at my desk rewriting some rules from a language called Aion into C++ in an Eclipse based editor (if my memory serves me correctly).
The IDE may have had some formatting and styling plugins.
Configuration Management was into a system that required you to check out files and reconcile difference on delivery.
There was no traceability to the task.
Code Reviews were not part of the automated workflow but part of the team processes.
When I had a batch of changes ready, or so I thought, for delivery I would zip up all the files and email the whole development team with the files and a Review Template Spreadsheet and put a meeting in the calendar for the next day.
In advance of the meeting the team would review the files and add rows to the spreadsheet listing the Location, Description, Category and Origin.
In the meeting all comments would be reviewed collectively and Result and Notes documented.
Dialling in team members in another location was via an international call, long before VOIP or video conferencing was used by the masses, to someone I had never seen in person and often formed a picture on my head of what they looked like.
We worked on Desktop machines and often printed the changed code files, a copy for everyone, to take to the room.
I won’t start on the booking of a projector, which may or may not work, for the others in the same location to be able to see.
At the time all of this was perfectly normally and it is easy to forget how far we have come.
The whole experience was often dry, in personal and felt like an exam where you could be humiliated in front of your team.
I still have a Review Record from my subsequent team from 2004.
9 related files were listed with changes and 104 comments added by different people!
So what observations can I make looking at it now?
1) The Origin field has options for each phase of the development lifecycle. This is interesting as we were considering a Review to not be a Code Review but used this template for all areas of the lifecycle.
2) Many of the comments are still things that we see today, however some can now be automatically handled by the tooling we have, such as formatting.
3) There is a lot of heavy paperwork for “audit” sake.
4) Reviews clearly took days to complete fully. This was less of an issue in Waterfall as Production deployments were very infrequent.
Jumping forward 14 years how far have we really come?
Tooling has come on leaps and bounds, we all have laptops and Skype for Business to name but two.
Traceability and automation with linting and analysis tools provide multiple options. We have Code Coverage and static analysis for security vulnerabilities. This should allow us to focus fully on the areas that really matter.
CICD means teams increasingly own their full lifecycle, instead of depending on other teams for infrastructure and testing.
We often have the ability to deliver changes that will be automatically checked and deployed in minutes to Production.
So in terms of Reviews what are we still doing as a hangover from the Waterfall and limited communication and tooling days?
Refresher on a couple of the core Agile statements:
“Individuals and interactions over processes and tools”
“Working software over comprehensive documentation”
And in our company direction on Coding Excellence we simply state that “All code is seen by at least two people”.
How well does your team Review Process compare and how agile does it score?
“Individuals and interactions over processes and tools”
Do you always refer to Code Reviews only? How about Solution Reviews instead that ensure design considerations are taken into account?
When do you request a Review? Is the first time someone else sees the proposed solution when you are “done” or do you have multiple informal incremental reviews?
When carrying out a review what is your motivation — to look for one-upmanship or spelling mistakes? Your IDE now probably has a multitude of tools to automate away all the styling concerns and let you focus on the actual solution.
Do you have a “Solution Walkthrough” with the developer in person or is it always remote and on your own?
“Working Software over comprehensive documentation”
Can you turnaround code changes and have them deployed within an hour or do you have to wait on a long rigid process with all comments recorded?
(When was the last time our team needed to look back for comments retrospectively?)
“All code is seen by at least two people”.
Using XP techniques such as Pairing and Mobbing should mean that all code is seen by at least two people and throughout its iterations, not just when “complete”.
Let’s do a Review on our Review Processes and wider techniques and see how we can improve our collaboration and turnaround times.
Use tools to facilitate increased and incremental reviews that focus on the Solution meeting the customer needs.
In “People and Code” Part 2, we will be take a journey into the world of “Behavioral Code Analysis”.
