As a developer at DRW, technical debt is often on your mind. Our front office teams work directly with their traders (often sitting directly next to them), and are exposed in real-time to their software needs. While sitting with the traders you see the immediate impact of your recent feature additions. The feedback loop is extremely tight - In the past I've come in to work, received a feature request early in the trading session, coded the change, deployed it to production, and seen the profits as part of that same trading day. In that kind of environment, you tend to care more about adding features than you do about having the most elegantly designed software in the history of the world.
But, you can't ignore code quality due to it's impact on delivery speed. There's a constant internal personal struggle between delivering features and keeping quality at a level that enables high speed delivery. Our technical debt is very visible, we keep reminders around to ensure we address our technical debt in the future. We also use those same reminders to prioritize which technical debt payoff will most benefit the team. The traders are also very aware of the technical debt, and it's often the case that they ask the question: Do you guys need to spend some time paying down this technical debt?
Working in an environment where the traders understand technical debt and embrace it's payoff is great, but it exposes other issues with technical debt.
Steve Freeman's blog entry, Bad code isn’t Technical Debt, it’s an unhedged Call Option, first got me thinking about different types of technical debt. That blog entry rang very true for me. I really liked the idea that selling a call option was a better metaphor; however, I wondered if it was something that could easily work in your average workplace.
I happen to work in a trading firm, so my customers know the implications of selling a call option. But, the entire idea of a metaphor is to understand one thing in terms of another. If you don't know either things, the metaphor doesn't really work. I don't think the average customer already understands options; therefore, I don't think the new metaphor will ever catch on.
But, I did believe it was a superior metaphor. So, I started looking at my bad code as selling calls instead of debt. In some cases the metaphor worked perfectly. We created an analysis tool that was mildly important to the traders and didn't have strict reliability needs. This analysis tool didn't have a single test. If the tool changed it's role, we would have had to put in a fair bit of work to ensure that it was more bug resilient. However, the tool served it's purpose and at this point I don't believe it's used by anyone. We saved a bunch of time (collected the premium) without ever having to make significant changes to the code (deliver).
However, in other cases the 'selling calls' metaphor didn't fit as well. In general, developers tend to call anything that slows them down 'techincal debt'; therefore, a slow running test suite would be considered technical debt. If everything that used to be called technical debt is now selling a call, then a slow running test suite is also selling a call. Except, that doesn't fit. I pay the time it takes to run the test suite several times a day. In the case of a slow running test suite, I think a high interest loan is a better metaphor.
Therefore, if all things that slow a developer down are 'technical debt' then you have some debt where interest is paid on an ongoing basis (slow running tests) and other debts where you'll only pay under specific circumstances (extending an application with no tests). I think this is a concept that is understood intuitively by most developers, but I wonder if adding visual type indicators to the identified technical debt would help with understanding and prioritization.
As a customer, I can imagine I'd appreciate knowing what is costing me on a daily basis and what isn't costing me anything today, but could cripple me tomorrow. And, as a team member I would be interested in highlighting ongoing pain and moving that higher on the priority list (assuming the other risks were reasonable). I imagine team members are already doing this subconsciously, but making it explicit could provide valuable to other members of the development team that have less context on specific situations.
In thinking about different types of technical debt, I wondered if there were other types of technical debt I was overlooking or incorrectly grouping with "high interest loans" or "selling calls". If any ideas spring to mind, please leave a comment.
I think the two metaphors that you have highlight the difference in cost vs risk. With the high interest loan, you have a fixed amount of cost and no risk. With the short call you have lots of risk and no cost (or negative cost because you receive premium).
ReplyDeleteAs SE's, we trade cost for risk, and vice versa, all day long. For example, we reduce the risk that there will be bugs in the system by writing tests. We do this because tests come at a fixed cost, whereas the risk of a bug is unknown and so is the potential cost of that bug. We also refactor, again at a fixed cost, because it reduces the risk that the next feature requested will cost significantly more to add.
Before I was introduced to XP, I spent years living with this risk. We would start a project and each new feature would be exponentially harder to add, until we would give up and build the system over from scratch.
You can also think of a reduction in risk as a reduction in variability. Queuing theory shows us that items flow through queues much more efficiently when they have limited variability, and as a result, a software team will be much more efficient if it can reduce variability of work items by trading variability for a fixed cost. The trick is to do this without stamping out opportunities for innovation.
If you have a reasonably talented team, I am pretty sure that these are the only factors that you need to consider when leading an iterative software project.
How much risk/variability am I carrying? Can I trade it for a fixed cost and be better off? Can I reduce the fixed cost and get the same risk reduction for cheaper? Are there cases where I want to sell fixed cost and buy risk?
I do not think the option metaphor works very well. While the decision you make to trade off quality could be modeled as a real option, the software project (and in particular its artifacts) itself is a risky asset with its own risk profile and payoff... Tests and methods modify the risk profile but technical debt does not affect it much. Technical debt affects more the payoff of the software project.
ReplyDelete@Jay Nice post. The point of the Call metaphor was to draw people's attention to hidden risks that tend to be dismissed in the short term. I also suspect that there are deeper, organisational costs with regular technical debt that can push a team over some productivity edge. I'd like to be able to prove that.
ReplyDeleteNow all we need to be able to do is price this stuff :)
@dbregeon No metaphor is perfect, but the Call idea can highlight hidden risks that many organisations don't see in their rush to make the next quarter. It might help to think in terms of a software product or system, rather than a transitory project.
ReplyDeleteI'm curious, what steps do you take to keep your tech debt visible?
ReplyDeleteNothing special - a standard cardwall.
ReplyDelete