What Can be Done About Technical Debt?

By Jeremy Schreiber


Picture this! Your team is working hard for years designing a product, growing rapidly and building success.  Then one day – it all comes to a grinding halt.  You are at a fork in the road, faced with a pivotal decision – do you stop current development to revamp all of your code - thereby enabling new and more powerful features, or do you continue working with your old mess of code, going down a deeper and darker path that you know you will never be able to dig yourself out of?  This is not just a problem faced by startups alone, nor is it limited to software companies either.  Technical debt is a real phenomenon and a real challenge to be faced by all – and if left unaddressed, it can cripple any organization, big or small. 

I’ll admit it.  Before coming to HBS I was unfamiliar with the term “technical debt”, yet I was well versed in the principal.  For years, at AMD, I worked on internal design tools whose foundations had been established long before I joined, and yet continued to evolve with time.  As long as the edits were minor tweaks, everything was fine – the existing codebase worked.  However, my goal was to introduce powerful new features that would enable our designers to be more productive.  However, every time I worked with the software engineering team, I was given the same answer: “The current code just won’t support that new feature and we don’t have time to revamp the code.”  And why couldn’t they rewrite the new code to support the features that could save hundreds of man-hours of productivity?  It’s because they were busy fixing holes and bugs in other software tools, saddled with technical debt on all fronts.  Technical debt was crippling our software engineers, and preventing our hardware engineers from having new more powerful tools available to them.

In yet another example, as a new hardware design team was being formed to design the next generation computer chip, management decided that the old codebase wasn’t good enough, so the best solution was to write a new one entirely from scratch.  Not only was this incredibly time consuming, causing massive delays in the start of the project, but ultimately countless resources had to be taken away from the old software team to help the new one, leaving the few people remaining on the old team to struggle even more with the technical debt of the old software.   In the mean-time, like any new software, the code was buggy, and never functioned quite the way they had hoped it would. Clearly stopping progress on one codebase to write a new one completely from scratch didn’t work and is not a sustainable model – in fact it almost crippled the company.  So how then can you deal with this problem?

One solution that worked for us was maintaining overlapping teams.  The first team is responsible for deliverables and deadlines.  They work on developing new features, and cleaning up small amounts of technical debt along the way, ensuring that the product stays on schedule.  The second team works in the background, with much less rigid deadlines.  Their job is to take the existing codebase and modify it – revamping and refactoring code as necessary, without having to rewrite the entire system.  This team should be treated as R&D, and as such, has plenty of time to test the new code across a variety of projects and scenarios, running through countless amounts of regression testing.  As the enhanced code becomes stable, they can roll it out to the schedule-based teams, and be there to support them in case anything goes wrong. 

This solution is quite powerful and effective, but it comes at a cost.  Namely, you have to support two development teams – which for a startup can be a very expensive proposition.  It also means you have a team that is working but not delivering a tangible ROI that can be accounted for directly.  That said, one can reflect on the situation Jeff Bussgang described in class and ask – which is more costly, a second team of developers, or ten months of stalled product design and a plethora of angry customers? 

Comments

Popular posts from this blog

Managing Your Online Persona, Part I

TCS IT Wiz 2013 Bhubaneswar Prelims

Interroger Prelims