Remember the computer programmer in Jurassic Park? He was a rotund loner whose workstation was littered with soda cans and empty potato chip bags. The Hollywood stereotype of software engineers is The Lone Coder, a social misfit who shuns human interaction. He can make magic happen with a few clicks of his mouse, but he probably does it from the solitude of his parents' basement.
In real life, The Lone Coder makes mistakes -- lots of mistakes. Answerable to no one, The Lone Coder designs a system only he can understand, and no one else has a prayer of maintaining or modifying. The Lone Coder is a threat to the growth, security, and stability of a computer system. Scariest of all, entire software "teams" can be full of Lone Coders, each one marching to his own beat, following her own whims, leaving a cloud of chaos behind in their wake. Their product might work, but it is a house of cards.
The defi SOLUTIONS engineering team takes the quality of our financial software for lenders very seriously. We know our product delivers freedom to lenders, but no lender is an island. Lenders must interact with vendors, customers, and partners. defi speaks this language of collaboration because we live it. The Lone Coder doesn't work here. We believe the highest quality product can only come about through collaboration.
One of the techniques we use to harness the benefits of collaboration is to write our software in pairs. Pair programming is a software development technique in which code is written by two programmers sharing a single keyboard. This doesn't mean there are four hands on the keyboard at any one time, typing at speeds so fast they'd make Mavis Beacon envious. In pair programming, one developer (the driver) has her hands on the keyboard and is responsible for composing the code. The other (the navigator) reviews the driver's code for quality and potential improvement. No one is ever locked into a single role; driver and navigator should switch roles often.
The benefit of this technique is obvious: two heads are better than one. The navigator is constantly watching the code as it is entered, pointing out mistakes and dreaming up scenarios the pair hadn't previously considered. She's like Inspector 12 on the old Hanes underwear advertisements -- nothing gets past her! But does this technique make any difference? Pair Programming Illuminated by Laurie Williams estimates code written by a pair to be 15% better than code written by an individual.
Pair programming has drawbacks, too. The first thing every sharp pencil boy and girl in accounting notices is the increased cost. Why pay two developers to write code that could be written by just one? Even assuming code written by a pair is 15% better, is it only 15% more expensive? Probably not, at least at first. But consider the cost of the initial creation of software plus the cost of its repair, its maintenance, and its bug extermination across its entire lifetime. If it is written the first time correctly, and thus doesn't have as many long-term maintenance costs, it's more expensive now, but significantly cheaper in the long run.
Economics aside, there are also physical challenges in pair programming. What if the navigator ate onions for lunch, and the driver can't stand the smell of his breath? If the driver has a cold and keeps having to blow her nose, how eager will the navigator be to take the keyboard when it's time to switch roles? What if you are a geographically distributed company and teammates aren't located in the same physical space?
While we do plenty of pair programming when developing our loan origination software, servicing software and other lending software services at defi SOLUTIONS, the problem of geographic disbursement is a very real one for us. We have software engineers in several different cities, and even in several different states. Teleconferencing, screen sharing, and remote control software all help distributed teams practice pair programming. But another technique is easier to manage for a team separated by physical distance, yet still provides all of the benefits of pair programming.
University courses in software development are usually called "computer science" not because it is an intellectual term that sounds distinguished on a diploma, but because many of the principles of science actually do apply. Effective software patterns are adopted through hypothesis, experimentation, and trial and error. Results must be based on evidence. And before a product (software) can be accepted by the community (our clients), it must undergo peer review.
In a code review system, an individual writes a new software feature all by himself. But before that code is allowed into production, it is meticulously reviewed by one of his teammates. This fresh pair of eyes provides nearly all of the benefits of a programming pair, even though the author and the reviewer never necessarily sit down together at the same keyboard. Code review also works flawlessly with a geographically diverse team. I can write code in Texas, check it into our repository, and it can be reviewed by Chris in Michigan. Plus, any bad onion breath or germs on the keyboard stay with the developer from which they came.
The drawback of a code review system is that it can become a meaningless rubber stamp. Bruce can become swamped with his own assignments and feel like he doesn't have time to review Diana's code, so he simply glances it over and gives it his stamp of approval. If that happens, there's no defense against the dreaded Lone Coder. A code review system works when the reviewer approves the code only if she would accept having the original author's name removed and her name put in its place.
Definition of quality
But what is a meticulous review? What's the definition of good software? What kind of standard are we trying to reach? At defi SOLUTIONS, a thorough review must include the following:
- First, the reviewer should run the software and use the feature the same way one of our clients would. But wait, isn't this supposed to be a code review? Sure -- but if the feature doesn't do what it's supposed to do for our clients, who cares if it is the most elegant piece of code ever written?
- So the new feature works as expected... Does everything else? Did something that previously worked get inexplicably broken?
- A requirement of our engineers is that they not only write new features, but automated testing software that verifies the feature works as designed. Are these tests present? Do they all pass? Do they fully cover as many use cases of the new feature as possible?
- If all of the above tests pass, only then is it time to review the author's actual code to ensure it is written efficiently, clearly, and that it does only what it is supposed to do. (No diverting fractions of pennies into The Lone Coder's private bank account.)
Reviewing the code is the last step in a code review? Absolutely. Remember: the point of these reviews is not to see who's the most elite hacker, or who has the most programming mojo. The purpose of pair programming and code review is quality, and the definition of quality is software that makes our clients' lives easier. Beautiful code that doesn't fulfill our clients' needs is useless.
There's no I in TEAM, but there is QUALITY
Does it take a village of software developers to give lenders freedom? Yes! But to be honest, some of those Hollywood stereotypes do have a hint of truth to them, so this proverbial village will have to be well stocked with pizza and Mountain Dew. Most important though is that the work table has room for a lot of laptops. At defi SOLUTIONS, it isn't our individuals, it is our author pairs and author/reviewer partnerships that are focused on delivering the most excellent product possible to our clients.
Also read from Mike Ripplinger: