Technical Debt is a phase coined by Ward Cunningham to help illustrate the pros / cons of releasing software in a quick & dirty fashion vs a long term, cleaner solution. In a nutshell, technical debt is much like financial debt, as it incurs interest in the way of level of effort over time.
Financial Debt comes with a very negative connotation in these tough economic times, but as Eric Ries stated recently it isn’t inherently a bad thing. Releasing early has it’s own benefits such as receiving much needed customer feedback for your product. These leading indicators may provide the direction you need with future software releases.
How does an agile team decide whether or not the technical debt they incur is acceptable?
I have a couple suggestions below:
Address Technical Debt in Retrospectives – Keep a running tab of your technical debt so that it doesn’t run rampant. Your retrospectives should include items such as Refactoring Debt Incurred and Refactoring Debt Paid. If you trend these data points over time and notice debt incurred going up like a hockey stick, it should be a cause for concern.
Release Early with Customer Feedback Loops – While there are certainly scenarios where a feature needs to be pushed out quickly, the code should include some level of empirical data gathering to measure customer impact. With tools such as Google Analytics and Mixpanel available, take the time to run A/B tests with your code. If your early release results in a 20% boost in conversion, it is much easier to reconcile the technical debt you incurred. Without this data however, you will be missing key elements to your decision process.
In short, be wary of teams that use the phrases “quick & dirty” with “path of least resistance” too frequently without empirical data to back it up. Keep your technical debt manageable by trending it over time, and bake in customer feedback loops to justify your early releases.
Tags: deployment, leanstartup, technical debt
Disclaimer: I witnessed this first hand as a junior technical lead several years ago. This is a stark reminder of how a neglected team member can suffer both professionally and personally. The names have been changed for privacy, and this person did not report to me.
It was early 2001, when Ben walked into the interview with a jovial personality. Ben’s resume was impressive with a laundry list of accomplishments as a Senior Software Engineer. We grilled him in a series of 2-on-1 interview sessions and at no point did he raise any red flags. Ben’s answers were articulate, and he was hired shortly thereafter.
Once Ben had joined the company, the IT Director placed him on production support for our evolving trade platform.
He did this (I believe) for 2 reasons:
- Since we had no training material, it was an easy way to have Ben learn the platform.
- It would place another set of eyes on our critical bug stream.
Ben sliced through malformed XML with the speed and precision of a Japanese master chef. One misplaced decimal point or node could result in thousands of dollars in gain loss, yet none of which happened on Ben’s watch.
As our start up matured, we adopted an agile framework to help quickly meet the needs of our clients. Our core offerings flourished and our teams gelled. This was great news except for Ben, who was still on production support after more than a year. The IT Director had either completely forgotten about Ben, or was unwilling to let him work on new functionality. I imagine if Ben had participated in our shiny new agile team we’d have to actually address our sustained engineering problems.
Ben’s personality slowly deteriorated over time as he watched his coworkers continuously roll out new functionality. One afternoon we found him underneath his desk, sobbing in a fetal position. Needless to say Ben wasn’t with the company for much longer.
What lessons can we learn from this tragedy?
- Good developers want to create code, not continuously patch it.
- Do not leave a team member isolated on a project with no end in sight.
- Training new team members should be mandatory.
- Single points of failure do not save you money in the long run.
Tags: project management, startup
Loading ...