One solution for the conflicts of Business vs. Technical problems

We’ve all been there! The argument over “the right thing to do”. This usually happens because of a conflict between business interests (for example meeting the deadline) and technical interests (for example keeping the code maintainable).

As a team, we faced this problem very recently, and we were forced to make the uncomfortable decision of taking the shortcut to meet the deadlines. But we made up for that by also creating a separate ticket to apply “the right solution”. This may seem very unnecessary, but I think this at least resolved our conflict. The reason I liked this tiny change of approach was:

• We “know” about this problem (aka a technical debt). The main reason us developers do not like the dirty solutions is because they will pile up. And they become eventually “impossible to do”. But now, we have items in our backlog that represent how far we are from finish line.
• This will let us deliver functionalities faster and let us focus more. Imagine when you are facing a nasty problem, and you could just focus on fixing it as fast as possible. At the same time, you will create a separate ticket for the proper solution where you can more freely spend time on the possible solutions or even come up with better solutions maybe because you have faced similar problem along the way and you saw a pattern.
• The trade-off between the conflicting solutions is visible for everyone especially the business owners. When I want to talk to the business owner, I can tell them we have the option to choose “Solution A” which we like but takes longer, and “Solution B” which will deliver the product on time, but will add the overhead of “fixing it later”. Based on personal experience, this might even lead to avoiding the “hotfix”!
• This solution will bring in a “planned periodical cleanup”. With changes like this and other technical tasks, we are adding to our technical debts. But the good thing about this solution is that, we will have items in our backlog that represent the amount of our “technical debt” and a rough estimation of how much time we need to address those.

Let me know if you had similar experience or had problems doing something similar.