| "Tech Debt" and "Code Quality" are myths. I know that is an unpopular perspective, but allow me to explain. To start with, for me everything is just a problem described in terms of its properties. What are some examples of problems I have encountered that were worth solving? 1. We have a server rendered site and an API. Changes to the server rendered site require matching changes in the API code effectively duplicating our efforts. If we re-implement the site as a single page app consuming the API we can kill two birds with one stone. 2. The lacking test coverage of a critical section of code matched against the frequency of changes to that code results in a frequent regressions and delays. 3. Unifying two divergent implementations will allow us realize a shared, multi-tenant deployment model for our partners. The load characteristics will give us the same point of presence for half the hardware. Why are these worth solving? Because they have objective rationales. The third embodies a strategic direction with real bottom line consequences. The case can be made "If you want this outcome here are the steps" Then the only question becomes "Do we want this outcome?" Many times "tech debt" and "code quality" are tossed around as easy justifications. They lack the intellectual rigor or organizational context to make a compelling case that its worth the opportunity cost. The person using those terms generally has strong feelings that its the right path, but can't really articulate why. In many cases there is no "why" and its more a of a "just because" In my experience "Tech Debt" projects that are actually undertaken or not called "Tech Debt" they are called "Lets do this because its important to the business and here is why" projects. |