Technical debt as disagreement is an interesting take. The pragmatic discussion between two members about practical debt is rarely a contentious thing. If you m

Technical debt as disagreement is an interesting take. The pragmatic discussion between two members about practical debt is rarely a contentious thing. If you moved quickly or flexibly to get a piece of functionality up with obvious corners cut, we all recognize it and have no problem with it mostly because the fix is also obvious (as obvious as why it happened in the first place). If you challenge someone’s larger architectural decision that is the root of most of the problems, now you’ve entered dangerous territory. Usually, the defense will try to reframe the issue as ‘practical debt’ of the kind I described above. ‘We needed to do this, we thought it was the right way to go, you get it right?’ - not really, no. Those decisions are handicapping the team. Technical debt is the number one contributor to quality of life imho. Good design that isn’t over engineered on one extreme end, or duck tape everywhere on the other extreme end, can help developers withstand everything the project throws at them. When a developer can easily understand and make meaningful changes to your codebase within an hour or two on any given day, they can withstand any type of siege (business shifts, design shifts, bugs, users, life). When the debt is too big, any one of those things can break the technical debt dam. It’ll be obvious when simple design changes can’t be made, or when a developer can’t adjust their workload down (will appear slow), or when new developers take time to make an impact (will appear dumb), or when the business changes and the product needs 5 new features that get push back (business will perceive friction). If we agree to disagree on tech debt then we’ll all pay the price.