Real-World Solutions for Developing High-Quality PHP Frameworks and Applications

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 ...