I did some code debt cleanup recently replacing some react state variables
because boolean state flags are trouble.
somewhere down the tree in one of these modal components this lurked
Needless to say we hit some bugs as in the testing process of this refactor. Because we were using a troublesome code pattern (multiple boolean state flags vs one state enum) there were all sorts of little unexpected things the old code had to do to actually work. For example, with this one workflow it would repeatedly call the cancel action on the modal as the final step when you clicked the confirm button. There was no clear reason for this looking just at the component where it happened, but it turns out this was to work around a complication inherent in the old implementation where there was no clear way to handle multiple sequential modals, so we had to really make sure this modal would get hidden. When doing the cleanup you don’t always know what odd tricks the previous programmer buried to make the previous pattern work.
To me this is a good illustration why tech debt cleanup is important. We made the code in this workflow significantly better here in terms of a developers ability to reason about it, and probably in terms of performance too. It was working before, sure, but the bugs we encountered were lurking in any case. We encountered them in this cleanup process, and with that there is often a temptation at the QA or management level to use this as justification to avoid doing tech debt pre-emptively, but I think that would be a bad conclusion. In my evaluation these problems could have just as easily been encountered the next time we went to work on any of this code, and in the later case the temptation to fix the problem with additional hacky workaround(s) would have been very great due to the low probability the original hacks would have even been visible or comprehensible.
In other words, and in keeping with the ‘debt’ metaphor, tech debt left un-dealt with has a tendency to compound.