The euphemism “technical debt” gets used a lot to describe code we wish we didn’t have to deal with. Code that uses two spaces of indentation instead of four. Code without unit tests. Code that conflates output with processing. In reality, that’s the code that runs your site and serves your customers. It’s not an enemy to defeat, it’s the first draft of a great novel, something to learn from and refactor. This talk is about strategies to treat your code – your “technical debt” – like a friend that needs to grow up, go to school, and get a job.
The challenge when dealing with technical debt is how to continue serving customers while improving the overall situation. Ignoring technical debt and attempting a rewrite are two common and extreme responses that each have their own perils. Often our first reaction to seeing code like this is, “that’s ridiculous, I’m going to rewrite this and then I can really build new features on top of it.” For self contained pieces of code that are easy to understand, that might make sense. But often that approach has just as many or more pitfalls than the code we think we’re “fixing”. We either don’t know where the edges are, or we don’t fully understand how other pieces of the system depend on one another. Or maybe there’s just too much to rewrite all at once. Taking on a rewrite risks second system effects and allows the legacy codebase to stagnate. Ignoring technical debt is just as bad: repeatedly introduced bugs, uncertainty about whether you’re able to ship, and hours spent chasing “Heisenbugs”.
So just as we live with the good (serving our customers), we have to live with the technical debt. But living with it isn’t the same as accepting it: we can be strategic, stop accumulating debt, and start learning from it. Living with technical debt requires a commitment to facing your code as it is, and continuing to engage with the existing codebase. It requires “tough love”. The pay-off is the ability to continue shipping features while improving the overall system.
This talk will discuss strategies for living with technical debt without accepting it: cultural best practices to embrace, and seductively simple ideas that you should probably avoid. This includes:
Examples and practices will be drawn from Creative Commons and Eventbrite, two very different organizations with very successful sites, each dealing with their own technical debt.
Nathan Yergler is a senior member of the engineering team at Eventbrite. Prior to joining Eventbrite Nathan worked at Creative Commons, serving as Chief Technology Officer from 2007-2011. In that role he was responsible for architecting and building the technical infrastructure for CC licenses, and managing the engineering team.
Nathan lives in San Francisco with his dog, Madeline. She bites.
For information on exhibition and sponsorship opportunities at the conference, contact Gloria Lombardo at email@example.com
For media partnerships, contact mediapartners@ oreilly.com
For media-related inquiries, contact Maureen Jennings at firstname.lastname@example.org
View a complete list of Velocity contacts