Best Kept Secrets of Peer Code Review
Modern Approach. Practical Advice
Jason Cohen
Ten practical Essays from industry experts giving specific techniques for effective peer code review.
I originally read this book back in 2010, at a time when I was heavily involved leading a software development team and was given the less than glamorous task of improving the Code Quality of the team. It was your typical Enterprise Software Development team, that had developed a few essential and critical Line of Business Applications, the problem was that these applications had gradually evolved into ever increasing balls of mud.
Its the same story that could be told in any organisation anywhere, involving similar plot lines involving :
- The original developer(s) are no longer around for a variety of reasons
- Business Requirements and use cases have constantly changed
- The applications have evolved rather than deliberate Design & Architecture
- Unforeseen regulatory changes had been introduced
- Additional use cases implemented
- Budget and resource restraints only accommodated a spit and polish approach to maintenance
The team I inherited were basically responsible for Development, Maintenance & Support of 10 Line of Business Applications. We were also apparently going to be responsible for developing new applications.
I've posted before on how not to do technical interviews and I remember that this particular organisation had one of those particularly odious interview processes, which to be brutally honest I very nearly just got up and walked out of, but I managed to bit my tongue and persevere. Although I don't think I was capable of concealing my disdain for the process.
I recall, that members of my interview panel prided themselves that all code was routinely peer reviewed and that no source code entered into the Version Control system without being peer reviewed. A claim I remembered at the time being a very bold claim.
I was completely surprised a few hours after the interview, that my agent called to inform me that the organisation would like me to start ASAP .
During my first few days, I was keen to discover and explore this robust Peer Code Review cycle and started to question my new colleagues about the process and their views on it. I even requested that I get invited to the next peer code review session to experience the wonder.
The peer code review process
It was a relatively short while after my request that I received my first invitation to my peer code review session, which basically comprised of "Hey mate, wanna come over here and check out this code I'm just about to commit?"
The peer code review process basically consisted of any developer on the team could be asked to sit with along side each other and talk through the changes that have been implemented in the file(s).
The developer walked me through the changes to the file, why he made them and the reasoning behind them.
On the face of it, this sounds what a peer review should be the basis of which a peer code review should mainly comprise. During the code review it appeared that, that was all that was discussed. Only the current development changes. In my opinion, this seemed fundamentally flawed, but resisting the urge to voice my concerns and introducing changes straight away, I decided to sit through a few more in order to gain a broader sample size.
It could've been just a one off experience and other developers in the team may have different approaches. This could've been an isolated experience, related to the particular work item.
I sat through another 10 Peer code Review sessions, on some occasions just as a passive observer, making notes of the interactions. Over the course of the week, I took on a ticket, implemented it and committed code and requested my own code review session.
On this occasion, I decided to implement code of a similar quality to what was being committed. Which in all honesty, was not really of any great quality at all. In fact, it was some of the worst quality code I had experienced.
If you've taken the time to read Code Complete, Clean Code, Philosophy of Software Design or even books like Java By Comparison you will have gained an appreciation of some of the finer aspects of writing good code.
Clean Code
A Handbook of Agile Software Craftsmanship
software developers irrespective of programming language or discipline should read this book
The truth is, whichever way you look at the Peer Code Review process implemented was nothing more than a complete waste of time and purely just a box ticking exercise. The developers and largely the organisation as a whole were receiving very little benefits if any at all from the process.
I realized that of all the issues I needed to address, paying attention and implementing a comprehensive Peer Code Review process was going to be fundamental part of the strategy. The key issue I knew I was going to encounter, was not going to be technical challenges but more Cultural and Human-centric. It was all about how I sold my intended changes and processes to the team and organisaton.
Adaptive Code
Agile coding with design patterns and SOLID principles
Applying principles from this book, will help you create code that accommodates new requirements and unforeseen scenarios without significant rewrites.
Why I read this book?
It was around this time, I started doing a lot more research on Peer Code review, one of my Web based searches, led me to the old Free Give away of this book. I am extremely happy I did, because this book provided all the answers I was looking for, with some great case studies and practical examples where teams and organisations in similar predicaments overcame their challenges.
What many people, in the Tech Industry at least, forget is that software is developed by human beings, and the thing that really matters in software is human to human relationships. All too often, I see software teams fail at this most fundamental point.
In the 5 dysfunctions of team Patrick Lencioni stipulates that the five dysfunctions are:
- Absence of trust — unwilling to be vulnerable within the group and operating in a place we now know as psychologically safe.
- Fear of conflict — seeking artificial harmony over a constructive passionate debate out of fear, apathy or arrogance.
- Lack of commitment — faking buy-in for group decisions creates ambiguity and uncertainty and a disbelief in the mission, vision and values of any organisation.
- Avoidance of accountability — ignoring the responsibility of self and peers to standards which results in counterproductive behaviour and lower levels of performance, innovation and support.
- Inattention to results — focusing on personal success, status and ego before team success.
The five dysfunctions of a team
reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. Outlining a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team.
Most code review practices in organisations, typically involve all 5 of these dysfunctions. More irritatingly code reviews usually turn into ego stroking fests and subjective opinion slinging!
What I liked about this book
The book itself is well written and easy enough to read in an evening, only weighing in at 164 pages cover to cover, Yet has more than enough information to help you make changes and implement practical ideas to help you change your Peer Code Review process for the better literally over-night! It certainly did so in my case.
Despite the fact that the book has been authored by the founders and developers of software company that has developed a suite of tools to help organisations improve their code review processes. Implementing the solutions and following the case studies in this book does not require you to purchase or implement their solution. It is possible to completely revolutionize your organisations peer code review process without even using their tools. However, obviously they would like you to try out their tools.
One of my favourite adage is also found in this book, which also highlights the most important aspects of Code Reviews. They are not about critiquing work or code, they should mostly be about collaborative learning.
I read I forget, I see I remember, I teach I understand
What I learned from this book
Peer code review is not just about having two (or more) sets of eyes on a given piece of code in the hope they are better than one. In my opinion that is a side benefit and not the goal. In my experience, this is where many organisations fall short when they start considering Peer code reviews.
The book uses a number of studies to make a good case for why (lightweight) code review should be used as a development practice. The suggestions were backed by research data that they analyzed and discussed, and they did a good job of explaining their conclusions with the prose.
- What is this Directory.Packages.props file all about? - January 25, 2024
- How to add Tailwind CSS to Blazor website - November 20, 2023
- How to deploy a Blazor site to Netlify - November 17, 2023