Code Is Pretty Much Everywhere. Why Isn't Code Review?
If you head over to code.org and take a look at some stats, you'll see an incredible trend. By the year 2020, there are projected to be 1.4 million additional programming jobs added to the global economy, while only 0.4 million computer science students will graduate in that time. Notwithstanding any people that make lateral career transitions, this projects a jaw-dropping 1 million more programming jobs than people to fill them.
Can you imagine? Recruiters won't just email you – they're going to start showing up at your house with fruit baskets, offering to dance for you. The demand for code is going to reach fever pitch with no relief in site and the pressure on us to crank out code as fast as humanly possible will continue to mount.
A Cambrian Explosion of Software
Where is all of this demand coming from? Well, think back to the early days of computer programming, when your only option was banging away at mainframes. The advent of the personal computer and standard operating system brought a glut of new programming work to the industry, as the computer began its invasion of homes and small offices. Next up, the internet spawned a new breed of program, and web development was born. Soon after followed mobile devices and the app stores that support them. And now? We're talking about the "Internet of Things."
Consider the journey of the computer. It migrated from labs to centralized locations to offices to homes to globally connected computers to cell phones and tablets and now, well, they're just going to be everywhere. And computers everywhere means code everywhere. The Internet of things means that your appliances, your clothes, your office supplies, and maybe even your pets are going to have chips, connected intelligence, and code. Refrigerators can tweet, family pets can be located if they scamper off, and Jeeps can be hacked. The world is changing both for better and for worse, but it is most certainly changing.
And so two trends collide: growing relative scarcity of [good] software developers and an explosion of code into everything that surrounds us. This is going to mean a lot more pressure on those who do write code to write a lot more of it, and faster. And I think we all know what happens to the quality of code when you rush to get it out the door. Could we be staring down the barrel of a lot of terrible code being hurried into everything around us?
Not necessarily, so what can we do? It seem as though it might be a little quixotic to suggest we somehow solve the puzzle of getting more people to fill these roles, so let's consider a route less dependent on public policy and social forces. In economics, labor shortages tend to drive efficiency and automation, so perhaps that's the ticket. We need to get more efficient – not at cranking out code but at keeping up with demand while writing reliable code.
The first thing that probably comes to mind is the automation of tests. We already do this today, in the form of automated unit tests, acceptance tests, integration tests, smoke tests, etc. Adoption here is widening, but it's hardly universal. For every software team with a rich set of tests incorporated into the team's build, there's another that's hand-editing markup live, in production without a safety net.
If relatively fewer people are going to produce relatively more code without a horrifying dip in quality, adopting of automated testing practices will have to grow beyond where it is today. But we’ll not only need to adopt it more consistently; we'll also have to get better at it so that it doesn't slow us down. It will have to be an integral part of software development.
Automated tests are excellent for catching incorrect or inconsistent run time behavior, but they don't really do anything, per se, for the compile time state of the code. In other words, it's possible to have code that passes a series of tests but is still difficult to maintain or alter, which can lead to slowdowns and other problems.
To help with this potential for waste, it's essential to automate the process of evaluating code for certain desirable or undesirable properties. This has the effect of keeping developers on track from the start, lessening the likelihood that valuable time will be spent later on slowdown and rework. Static analysis will make a formidable one-two punch when combined with automated testing to pace demand without sacrificing quality.
Automated tests and automated static analysis share an obvious common thread: they're automated. Automation is a key component to increased operational efficiency, so the more we can have computers do for us, the better. Does this leave any room for a manual activity like code review?
It will be easy for future managers to argue that it does not. After all, peer review and pair programming, they will argue, actually reduce operational efficiency by having multiple people work on something that could be handled by a single person. It's wasteful, they'll claim, to have a developer reviewing another's code when that reviewer could, instead, be writing code.
There's only one problem with that reasoning. Code review is just so inconveniently effective. For all that static analysis and unit testing are celebrated, neither is as effective at trapping bugs as a formal, peer code inspection. Code review is just too important to skip.
And since we can't skip it, the only path forward is to get better and more efficient at it. We're going to need tools that lower the barriers to entry as much as humanly possible. It'll be essential to be able to have your code reviewed by anyone, in any location, at any time. Intelligently highlighting differences and bringing focus to the key changes will eliminate friction that exists today by cutting useless paging through files. And managing the review workflow intelligently will become critical; Outlook and post-it reminders just won't cut it.
The emerging gap between supply and demand for software development is striking, but we need not be daunted. If there's any industry that's up to the challenge, it's ours, since automating for the sake of efficiency is basically our charter. To do it, we're going to need to go faster without sacrificing quality. That means we need to come up with ways to automate good practice and quality assurance. We won't get there by scrambling; we'll get there by sticking to our good practices and creating and adopting tools that makes them more efficient.