The Technical Debt Slippery Slope

I had a conversation last week about a new feature implementation that the developers were struggling to get working. They had based it on existing feature, but were having problems getting it to work.

After some investigation, I found the issue, but also that the approach they were taking was no longer optimal. There was a simpler way to do it.

But it works just like this existing feature.

So at this point, what do you do? Carry on with the less than optimal method, be consistent, but increase the size of your technical debt OR go with the more optimal approach, but now have a new feature that works differently from the rest?

It is a classic consistency versus correctness question.

This is the technical debt slippery slope. You may think that you are not going to have any, but eventually you will discover a better way of doing something.

For me - correctness wins. Mostly because I do not believe the majority of technical debt ever gets fixed. The chances that you will go back and fix anything like that is vanishingly small on a live product that constantly needs new features and bug fixes more than it needs a change in developer philosophy. Developer philosophy is hard to sell.

And also because you do not know how many similar features in the future will require a similar approach. You may now have 3 or 4 which are no longer consistent, but you may add another 30 that will.