Chapter 5. Quality Assurance at Digg Inc.
Robert Balousek, Matt Erkkila, Ian Eure, Bill Shupp, Jeremy McCarthy, and Brian O'Neill
WHAT'S IN THIS CHAPTER?
Software development philosophies at Digg
Overcoming the problems posed by legacy code
Evaluating development team, project, and code base size issues
The importance of unit testing
Overcoming resistance to unit testing
The characteristics of testable code
Using mock objects
Quality assurance in an agile environment
PROBLEMS WE ARE FACING
The first version of Digg launched in 2004. Written by a lone developer, Digg let people post and vote on links from around the Internet. Fast forward to 2009, and with more than 70 employees and more than 1.1 million lines of code, Digg serves about 39 million unique users and millions of page-views per month. With 16 developers split into four distinct teams, assisted by four QA engineers—one for each team—we push new code live to the site almost every single day. Sometimes those pushes are two to three lines of code to fix a bug, and sometimes they are 2,000 to 3,000 lines of code and a whole new site feature.
At the beginning of 2008, the engineering team at Digg was still relatively small, with eight developers and no QA team. We operated using a waterfall methodology and large requirement documents, moving through a single phase of the process at a time. Using this methodology, we were releasing feature sets every three to four months. Because our release cycle was so long, and the releases we were ...