Tech Debt Musings

I did some code debt cleanup recently replacing some react state variables

The Cleanup Example

	someModalVisible: false,
	otherModalVisible: false,
	specialModalVisible: false,
	neatoModalVisible: false,
	superCoolModalVisible: false,

with

	activeModal: 'none',

Because boolean state flags are trouble.

Somewhere down the tree in one of these modal components this lurked

handleConfirm() {
	handleOk();
	onCancel();
}

WAT?!

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.

The Temptation

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 fine” before, sure, but the bugs we encountered were lurking in any case. We encountered them in this cleanup process, and with that being the case there is often a temptation at the QA or management level to frame valuable work like this as “nothing but looking for trouble”, and use it all as justification to avoid doing tech debt preemptively, a sort of perversion of “If it ain’t broke, don’t fix it” philosophy, but I think this demonstrates why that would be a very bad conclusion. In my view 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.