Foreword
I started writing this article in September of last year (2020) when I was still a consultant. It was one of my standard consultancy rants about clients not "getting" things. Having now spent a while out of the consultancy bubble, I finished the article because one of our engineering managers asked me about how we can justify tackling technical debt over prioritising a feature. I referenced this article to him but then realised that I hadn't finished the article. So 90% of this was written in September 2020, then, if I remember correctly, I tweaked the spreadsheet because it was faulty, then today I added a link to the sheet and a conclusion.
The Danger of Dogma
I've written and talked about the danger of dogma in the past but I'd always been talking form the perspective of the consultant. In particular, while I was at ThoughtWorks, I was aware that certain aspects of engineering practice had become so ingrained into the ThoughtWorks culture that many of my colleagues talked dogmatically about using them. Whilst I would certainly support the adherence to these practices, talking dogmatically about, in particular, pair programming, never helped us to persuade sceptical clients of the merits of it. In one case I recall, a colleague of mine who had come through the graduate training program admitted to me that he was incapable of forming an argument in favour of pair programming because it was all that he had ever known in a business context. Thus, dogmatically advocating pair programming was his only possible approach.
Anti-Dogma
Just like patterns are anti-patterns are a thing, I've noticed recently that people can develop powerful negative feelings toward certain practices that I'm starting to think of as anti-dogmas. Commonly I have seem strong opposition to Agile ("it doesn't work here"), pair programming ("why do you need two people to do the work of one person?") and especially Technical Debt ("why do programmers always want to gold plate things?"). If you meet this kind of opposition to what you consider to be sensible solutions to obvious problems it can be extremely wearing. I'm happy to discuss with people what their concerns are and what other solutions may exist but when the other side of the argument is being dogmatic it brooks no possible discussion.
Trying Every Argument
For the past 6 months or so I've been working as a Delivery Principal across a few different accounts and dealing directly and indirectly with various stakeholders. We have had some success at these clients, notably in going through a series of workshops with one sceptical (but not dogmatic) client to illustrate the damage to the business being caused by burgeoning technical debt and the urgent need for us to find a way to start paying it down.
One of our client stakeholders (I'm going to call him "John" in this article, obviously not his real name), however, has shown himself to be virtually immovable despite all evidence. It is John's firm belief that the only reason why delivery is slow is because the developers don't work hard enough. He has said to me more than once, with a straight face, that if he "saw more urgency" things would get done better. He has continually refused our suggestion to put in place a methodology to measure the four key metrics and thus start to understand what "better" or "worse" may mean for the company, he just knows it isn't good enough. He is dogmatically opposed to, amongst other things, pair programming, TDD, any kind of context sharing and the concept of any development team deploying and running its own code.
Over the course of the whole engagement, now in the region of 15 months, we have tried many different arguments to attempt to persuade John that it is vitally important for the continued existence of their company that they take seriously the technical debt that has been accumulated and the effect that it is having on their ability to deliver new features in a timely fashion. We have failed in this endeavour. No matter how much we talk about "the weight of opinion in the industry" or "recent research" or "authoritative sources", John refuses to engage in these conversations, because he is so convinced that he is right. It is quite staggering that he seems to think he knows better than, amongst others, Mary Poppendieck, Ward Cunningham, Martin Fowler, Kent Beck, Nicole Forsgren and a host of others that most people would consider to be worth listening to.
The Trigger
The trigger to do something different finally came this month. After the relationship with our client had stagnated for a time and it has become increasingly difficult to engage John in conversation (lockdown has had something to do with this admittedly) we asked our senior leadership team if we could consider how we might accelerate the conversation with our client. We want to get to a stage where we can start to work in the way that we know will be better for all parties or work on our exit strategy from the client. In order to ensure that we had done everything we could before considering walking away from our client, myself and my colleague were asked to put together a proposal to take to John that could "reboot" the relationship and hopefully make it better for everybody.
In His Terms
The substance of our proposal is not very different from something that we proposed just before lockdown. The difference this time is that we know John is not going to respond to any kind of persuasive argument. The only thing we think he may listen to is a finance based argument or an argument that can guarantee, or make more likely, the delivery of features "on time". So I was asked to prepare something that would appeal to John and hopefully that would get him listening to us.
Continual Improvement Program
My first instinct for the proposal was to articulate what giving us the responsibility for a continual improvement program whilst still taking responsibility for the delivery of features (to be agreed) might look like. This approach had worked in one of our other clients in the recent past, enabling us to move from low value tactical "just get it done, I don't care about quality" work to a combination of continual improvement work focused on always improving our ability to deliver the features the client wants. Unfortunately, to get John to listen to this argument would involve him first admitting that there is a problem that needs to be solved. We don't think he understands that there is. He accepts that the solution is not perfect but he doesn't accept that it is valuable to invest money in making it any better. After all, he argues, it works.
Delivery Responsibility
We spoke internally about taking delivery responsibility for the work. This is a tricky thing and could be seen to be the start of a slippery slope towards a fixed price delivery which is something I never want to be involved in. We felt that we had to offer to take delivery responsibility in order to get anywhere in the conversation but in so doing we have to be allowed to deliver. We can't carry on with the current fractured value stream and broken (and hugely costly) automated tests. In order for us to be confident of being able to deliver on whatever expectations we agree we need to be able to address the technical debt items, large and small, that we know are there and impeding delivery. But we fear that despite all evidence John will not give us the empowerment we need to deliver which will make it unacceptable for us to take on delivery responsibility. So how can we possibly close the gap?
Technical Debt Compound Interest
I have read a lot of articles about technical debt incurring interest but couldn't recall ever finding any mention of what the numbers may look like and how they may affect the bottom line. I decided to look again to see if I could find anything that looks like a financial model. I found this article that mentions that different "interest rates" exists, but no other context. This article is fairly typical, talking as it does in generalities and principles but no hard numbers. I did find this research paper quite interesting but actually it was far too complicated for my purposes, I just wanted some kind of quick and dirty model of what technical debt costs.
Building a Model
I thought back to an article I had written for the Codurance website a couple of months ago on the cost of doing nothing. I couldn't remember exactly what I'd written but I do recall that the argument I made was that when you "do nothing", meaning when you refuse to address historical technical debt, things get worse and it gets harder to deliver things. The cost can be evaluated in wasteful processes but the far more interesting number, if you can calculate it, is the cost of not having new features to use. We normally call this opportunity cost. But what is a sensible, or quick and dirty, measure of opportunity cost and how does technical debt influence it?
Inspired by being encouraged to make some assumptions in the costings of my proposal I thought I would play around with what looked like some sensible numbers to see how allowing debt to pile up or conversely paying it down, would affect the return on investment in some reasonable horizon. I used the obvious tool at my disposal - Google Sheets. I constructed a simple model of a development group that can sustain three concurrent streams with a backlog of items that are all scheduled to take (according to estimates) 3 months to complete. They are staggered to start on the first day of each month.
Parameters and Outputs
The parameters I can vary in the version I have at the time of writing are:
- Baseline. This represents the current velocity of the teams. If it is 1 then the estimates are accurate. If you set it to a number greater than 1 then the delivery will take longer than the estimate. So if you set it to 1.2 then each delivery will take 20% longer than the estimate.
- Tech Debt Interest. This parameter represents the rate at which tech debt interest is accumulating or the rate at which it is being paid back. If the organisation does not care about quality and the situation is deteriorating, the number will be greater than 1. If the organisation is making real efforts at continual improvement this number will be less than 1.
- Feature Value. The model assumes a single monthly value for a completed feature for the purposes of calculating a ROI. This is often hard to calculate in real life but I happened to know that in John's case feature value is fairly well known because most features on the roadmap are implemented in response to signed contracts with clients that have a monthly value.
You can view my spreadsheet here. This is a read only access but you should be able to copy the data and play with it yourself.
Conclusion
The results are quite interesting because of the power of compound interest. If you assume that you incur a cost of 1% per month on your ability to deliver new features you'll see that very quickly the overall financial bottom line deteriorates. In fact, the way I currently have it set up (3 parallel streams, feature value of £50k, 3 months to deliver a feature), that 1% monthly degradation in your ability to deliver features, which will not be noticed month to month, will cost just shy of £0.5M in the first year.
In reality, I think ignoring technical debt will incur a bigger cost than 1% per month (I haven't done the maths in detail though I have worked as a consultant in some places were upwards of 50% of developer time was attributable to "waste" because of tech debt). So if you use a model like this and put in what you think are realistic figures for your organisation, perhaps based on some evidence you gather of time wasted over a time period, you should find you can make a convincing argument for making tackling technical debt a first class deliverable.
No comments:
Post a Comment