Going TDD

As the new guy on the Ohloh development team, I’ve been immersing myself in the details of Ohloh’s implementation. Do you face similar challenges to the ones we face at Ohloh? We have a body of code that has been in development for some 7 years, with all the technical debt that implies. Well over a billion records in a database, over 86,000 lines of code, thousands of active and dedicated users. And we have a long list of features that we’d like to implement. Oh, and a few bugs – imagine that! Ohloh’s crawlers continuously work their way through nearly 560,000 projects in hundreds of thousands of repositories across well-known forges and foundation sites, vertical hosting sites, and single-project sites supporting the most widely adopted SCM systems, with remarkably few failures considering the diversity of the FOSS world. Serious kudos to the team who built this!

Now, to not diminish their efforts and contributions in the least, we observe a lovely quotation from Edsger Dijkstra:

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

7 years of code writing, growing functionality, changed ownership and business priorities, and we have the completely unsurprising and standard mix of “wow, that’s brilliant” sometimes right next to “what the heck?” code. Oh, and a dearth of test coverage. That sets the stage for where we’re going. In previous positions I’ve had the opportunity to learn to use test-driven development. The Ohloh team has been messing around with this methodology for awhile but more the facade and intent, rather than the complete, disciplined adoption of this technique. So, to spread the wealth, diminish our pain and pursue the gain of TDD, we’ve assembled some internal notes, guidelines and policies, and we’re aligning our coding styles and conventions, design patterns, refactoring choices and test development across our geographically spread-out team, to help us accelerate our progress and keep on bringing you the new features and analyses you want from Ohloh.

Which brings me to the real point of all this. Gary Bernhardt of Destroy All Software has some inspirational videos, including one on building a test suite that does a great job of illustrating the process. Many thanks to Gary for producing this series and his blog, extracheese, and for sharing his wealth of expertise with the team. And, guess what? Gary was one of the direct contributors to the Ohloh code back in its early days before Black Duck acquired the site. That’s serendipity!

About Peter Degen-Portnoy

Mars-One Round 3 Candidate. Engineer on the Open Hub development team at Black Duck Software. Family man, athlete, inventor