Why the Code Review Process at Pied Piper is Broken

In a recent episode of Silicon Valley, developers at Pied Piper capped off a grueling sprint to repair damage from an AI bot gone rogue in the previous week.

If you are unfamiliar with the HBO show, it follows Pied Piper, a ragtag startup in the valley. This season, they have 40 employees and are aiming to develop a new, decentralized internet.

When the sprint finished, Dinesh and Gilfoyle, senior developers at the growing startup, handed over their code to another senior member to review. While they waited, Dinesh started attributing his coding quality to godly powers and boasting about how he definitely created fewer errors than Gilfoyle.

Dysfunction and bravado is nothing new to Silicon Valley so it shouldn’t be a surprise that their code review process follows suit. Before offering some suggestions to the Pied Piper team on how they could improve, I want to preface this by saying that every team should shape their review process to fit their needs. I’m sure many startups end up with a code review process naturally rather than intentionally. With that said, these are three best practices that every team should consider.

  1. Conduct Shorter and More Frequent Reviews

Even though the Pied Piper team uses a Kanban board and works in sprints, their review process is more waterfall than agile. A code review process that is embedded into a development workflow throughout a sprint can actually be a great way to push forward an agile approach and increase efficacy. In this case, they only start code review after the rigorous three-day sprint is over.

Handing several hundred lines of code to one developer to review in one afternoon and then pressuring him to hurry just reduces the quality of the review. SmartBear published a study of a Cisco Systems programming team that revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. If you exceed 400 LOC, your ability to effectively find defects diminishes. To increase efficacy further, we also recommend not spending any more than 60 minutes on one review session. Breaking up a review into smaller, multiple sessions enables reviewers to increase their efficacy finding defects.

While binging an TV show can be a great idea, binging a code review is not. It is negligent.

  1. Promote Code Ownership, Not Code Hubris

When Dinesh believes that he has created fewer errors in his code than Gilfoyle, Dinesh exhibits what can only be termed code hubris: a foolish sense of coding invincibility. He proceeds to barrage Gilfoyle with 200 (increasingly cringe worthy) insults. When it is revealed that Gilfoyle actually produced better quality code, Gilfoyle retaliates with an especially vulgar comment.

While there is nothing wrong with a little healthy competition, teams should strive for a coding culture that encourages code ownership but discourages hubris. With the complexity of today’s projects, defects or bugs are inevitable. Coding hubris makes individuals natively defensive. Code ownership makes developers more collaborative. Identifying errors should not trigger public shaming (no matter how poorly executed); it should be celebrated. It means that those defects will not slip through to later phases of development where they are more expensive to fix. Choose collaboration over competition and your team will solve more problems than it creates.

  1. Prioritize Transparency Over Hierarchy 

Part of the reason that this code review jousting even took place is that Dinesh couldn’t see the review of Gilfoyle’s code and vice versa. Because they are part of the company leadership, they had their code reviews conducted privately.

If a team’s best developers work in isolation because of their status, the rest of their team misses the opportunity to learn and improve. If Pied Piper made its code review process more public and transparent, they would cross-pollinate skillsets and better standardize the code entering their code base.

I don’t want to speculate on what tools a fictional development team is using, but if Pied Piper were conducting reviews via pull request through a source control management tool like GitHub, then other developers wouldn’t necessarily have visibility into the status of reviews and the number of defects found anyway.

Code review tools like Collaborator by SmartBear (try it for free) enable teams to open their review process up more with additional review roles like observers and moderators. Dinesh and Gilfoyle are leaders at the company and coding experts. If Pied Piper had a tool like Collaborator, new members of the growing startup could be added as observers to reviews, allowing them to see how these two senior developers write their code. Senior team members can also be moderators on code reviews so they know what common errors are popping up and what training they should focus on.

Centralized Code Reviews for Creating a Decentralized Internet

If the developers at Pied Piper ever decide to turn down the chaos, adopting a peer review platform that supports these practices would be a smart move. If you are interested in other ideas for how your team can increase the effectiveness of your code review process, you can read SmartBear’s 10 Best Practices of Code Review for a comprehensive list.

 

 

Speak Your Mind

*