Two developers. One Backbone tutorial. One of us is an avid hockey fan. The other is a bit of a sci-fi/fantasy nerd. Therefore, it only makes sense that the app we'll be building is a fantasy hockey league website during this tutorial series. Because seriously - who doesn't want to see Darth Vader vs. Sauron on the ice? An epic seven game series of elves of Lothlorien vs. stormtroopers of the Death Star? Yes, please. I'm sure there's a "one puck to rule them all" joke in here somewhere. I'll leave that exercise to you, dear reader.
A while back, I worked on a project that required persisting data to multiple databases. The requirement was to save some data to a Microsoft SQL Server (which hosted the billing application data) and save a different set of data to an Oracle database (which housed the database for the flagship Online Transaction Processing [OLTP] system). Both of the database servers were protected by the almighty firewall, valiantly protecting the valuable database servers from a variety of virulent violations.
Ailing attempts at alliteration aside, here’s a high-level diagram describing the application I’m talking about:
I’m sure you’ve heard of the 20% doctrine implemented by companies like Google.
In a nutshell, they encourage their developers to spend 20% of their time working on anything they want. The purpose is to inspire innovation and help keep developers engaged at the company.
I ran across this article in which the author makes an argument against using this development incentive. He argues that “100% of work time should be used for work and side projects should be done on your own time.” I’m sure I could write pages arguing both sides of this statement, but don’t worry, I won’t. I will however, examine one specific comment he made: “… it's better to find the right fit in a company that gives us work we're interested in 100 percent of the time.”
In the series opener, I wrote about “optional” software development practices like Test-Driven Development (TDD), Continuous Integration (CI), data migrations, one-click deployment and code review which are fundamental to how we build software at Fairway, but are often touted as optional and embraced by a small percentage of development shops.
In this post, let’s dig into one of the “optional” heavy-hitters, code review.
There is any number of reasons why code isn’t reviewed at all shops – every reason from the presumed time/cost commitment being too high, to just not understanding the true benefit or how to get started, to a general aversion to change. My two favorite reasons include protecting developer morale (i.e. developers can’t handle having their work critiqued) and naively thinking there’s no need/value since developers are producing a good product already. Oh brother. Perhaps worse than avoidance, though, are the truly unfortunate cases where the fears of the skeptics are the reality, where teams preform code reviews poorly. Here, a lively roomful of peers nitpick and bash away on Johnny’s code or, quite the opposite, the review becomes a total snooze session. In either case, the review is probably scheduled too late in the project lifecycle so there’s no time for anything constructive to be done in response. There’s absolutely no value – just wasted time.