- Write a list and check it twice
-
Over the weekend, I read a great article by one of my favorite New Yorker writers, Atul Gawande. The article (currently available here) introduced me to a recent development in intensive care units: the checklist. A professor at Hopkins one day decided to see if traumatic complications could be reduced by simply mandating that nurses and doctors follow daily checklists.
The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs.
Medicine has gotten so complex, that even trained experts will mess something up at some point. The only solution was a simple list of tasks, and an organization willing to enforce that the list was followed.
Reading this article reminded me of one way my team keeps a high level of code quality - checkin checklists. We have a wiki where we list out all of the things a developer is expected to do before checking in any code changes. These tasks include building (duh) but also running all the unit tests, running various static code analysis tools, measure code coverage, etc.
While this list is helpful in and of itself, we've found over time that as these steps go from being manual and unenforced to automated and required, the level of code quality goes up. Build breaks are non-existent. Unit tests don't get stale and broken. Many bugs are caught before the code changes are committed.
We use a home brewed tool that takes developer's changes and runs them through a battery of steps, including various kinds of builds, running tests, measuring code coverage, and really anything that can be put in a batch script. We try to keep this process to between 30 and 60 minutes by parallelizing to multiple machines and tweaking the set of tests that have to run, but you get the idea. We've even gone so far on one project as to have every checkin deploy a website to a server, install client code on two other machines, and run automated multi-machine tests against it.
Obviously, process has to be balanced against agility, but I think there is a lot of value to the notion of checklists as long as they can be enforced without unreasonable overhead.
- Introduction
-
Hi there, and welcome to my brand-new blog. For a long time, I've thought about starting a developer-focused blog, but two things generally held me back. 1) I needed a good title, and 2) I needed a decent subject that I actually knew something about. Hopefully, the former is solved (see above) and maybe I can take a crack at the latter too (see below).
This blog will be a place for me to gather experiences, thoughts, and useful nuggets about building web sites Better, Faster, and Stronger, The notion that web front-end development can be an engineering discipline too is starting to come in to vogue, with help from folks like the Yahoo UI team. Too often web sites are thrown out there without thinking of cross browser compatibility, unit testing, automatability, performance, and scalability.
My day job is at Microsoft, where I work on Windows Live SkyDrive, a free cloud storage site. In building the site, we focused a lot on building it the right way from the get-go, and are working to steadily improve it. I hope to bring much of what we've learned in the past year plus to this blog.
While you're waiting for my words of wisdom, check out Dan's blog and our team blog for some juicy nuggets.
