Speaking at Agile DC on October 8, 2013

I’ll be speaking at the Agile DC Conference on October 8, 2013, during session 3, 1:45-2:30.

Here is the full synopsis of my talk:

This presentation describes an extract, transform, and load of key commit and code-quality data from the build system to a code-quality database. It will cover how the database was used to transform two large project teams by baking quality into the build process in an Agile manner.

Many talk about technical debt in abstract terms. This presentation defines it in terms of actual code metrics and how they can be measured and tracked in an Agile manner. It will explain important details about the three groups of debt_static analysis, testing coverage, and class metrics.

How much unit test coverage is enough? Management often sets a standard of 80%, assuming the 80/20 rule is the most cost-effective. However, which 20% should go untested? This presentation asserts that 100% is an attainable goal and will detail how 100% coverage was attained as part of normal maintenance. Development culture changes when the standard becomes 100%.

Debt is incurred under various pressures and is paid back later. This is especially true with coverage and metrics debt. Tracking debt is essential to making it visible and enabling its reduction later. Tracking techniques are explained. The role of reviewers and code-quality automation is explored.

Techniques for tracking the error rate of actual commits are explained. Outstanding technical debt management reports are presented and explained along with their relationship to a trouble-ticket system.

A four-year case study of a 12,000 class, 2 million-line Java system with 25,000 commits of 250,000 program changes by 175 developers will be used. Unit tests increased nine-fold to 36,000, raising the branch/line coverage from 27% to 82%. A total of 5,500 technical debt items in 10 debt categories were identified, tracked, and resolved. A similarly sized C# system will also be used along with two different version-control and build systems.

The role of designing and writing testable code is explored. Architecture decisions can enable higher testability. For example, functional programming enables already tested code structures to be employed.

You’ll come away with ideas you can apply immediately as well as a longer-term blueprint for an architecture and process to attain zero technical debt in your organization.

To register for tickets, check out the AgileDC website, and feel free to message me or leave a comment about anything specific you’d like me to cover in my presentation.


One thought on “Speaking at Agile DC on October 8, 2013

  1. Greatly enjoyed your presentation at AgileDC yesterday; very informative. We are in the process of setting up a Sonar code quality feedback loop but you are definitely ahead of us in your implementation. Would greatly appreciate a copy of the slides if that is possible. Thanks again for a great presentation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s