Technical debt naturally accrues in any large codebase. This is particularly true with development that deals with a high proportion of legacy systems, or any team pressured to move more quickly than they would ideally prefer, a.k.a. every development team.
The conversation ranged along a variety of strategies to reduce tech debt, with consolidation emerging as a theme. Combining multiple APIs into one, the use of micro services, decoupling dependencies in general. Viewing maintainability as the most important aspect of engineering helps reduce tech debt. In many cases legacy systems are only legacy because they weren’t maintainable.
Getting buy-in from business is essential, and often difficult. Technical debt can be a black box to non-technical people –there’s no good parallel in other aspects of a business– and it’s difficult to get business folks to understand technical debt. It’s essential to communicate finite business benefits when making the case for time to reduce tech debt. “We’ll spend two weeks to make the site faster and more stable” goes a lot further than “the codebase is a mess we need to spend two weeks fixing it.” When communication fails, developers find themselves needing to sneak tech debt reduction into normal feature development. Rue La La does a feature freeze in Q4 to allow devs to tackle technical debt, but this is very much the exception rather than the rule.