![]() ![]() How much time and effort are developers spending on tasks that are not adding features or removing features? We can talk to folks outside the engineering team about that number. To fix these problems, choose something measurable to evaluate the quality of the system. In all seriousness, this is a huge reason that spending three weeks paying down tech debt, carte blanche, often does little or nothing for the team’s velocity after those weeks have ended. So when each engineer finishes their gang-of-four-fueled refactoring bender, the code is no easier to work in than it was before: it’s just different, so no one besides the refactorer knows it as well anymore. The thing is, those bugaboos rarely intersect with the code’s most pressing maintenance challenges. Engineers love tech debt week because they get to chase down their personal bugaboos. We spend “tech debt week” doing our pet refactors instead of actually fixing anything. ![]() Whoops.Įquating tech debt to bad code also allows us to conflate “this code doesn’t match my personal preferences” with “this code is a problem”-which, again, is fine, until we’re under a time constraint. A year later, we’re back where we started. There’s no need to revisit, document, or test this code it’s just that good. Luckily, a product manager happened to mention the situation to a lawyer at the company before the engineering team got very far, or it might have been a showstopping compliance issue.Įquating tech debt to bad code also allows us to believe that if we just write good enough code, we won’t have tech debt. For privacy reasons in their industry, it’s illegal to store these two particular pieces of personally identifying data in the same table. After spending a non-negligible amount of time bashing the database design and dreaming up ways to fix it, the team learned that their plan was…illegal. The team assumed that the structure remained in place because of inertia or because changing the database structure had backward compatibility implications. I once worked on a team that complained ad infinitum that customer information required a query that drew from two different tables. This constraint explains the loathsome characteristics of this code, and it also prevents us from doing our own genius solution. It allows us to assume that the prior developers just sucked at their jobs-which is uncharitable, but fine, until we realize that there was actually a constraint we didn’t know about. And we can find that terminology by dissecting what we mean when we say “tech debt.” Tech debt is more than just bad codeĮquating tech debt to bad code allows us to fall into traps. We, the engineers, have to examine our terminology. When businesspeople don’t want to grant a “tech debt week” because they saw with their own eyeballs that the last one improved the team’s capacity zero percent, how can we expect them to grant us another one with alacrity? They remember the last time they granted those weeks: within a month the team was underwater again. It sounds to the business like the engineers are asking for three weeks free from the obligation to release any features. Each conversant assumes they know what we’re all talking about, but their individual pictures differ quite a bit. Here’s the effect: the minute we trot out the term “tech debt,” everyone is upset but no one is listening. Engineers? Their answers vary the most, but often they’ve got something to say about “bad code.” We’ll return to why “tech debt equals bad code” is such a scourge, but first we have to address the effect of a bunch of different people defining the same term differently in the first place. Product folks lament how it means they lose three weeks and get no features out of the deal. Designers say it means the design can’t look the way they planned it. So they slap the term onto whatever happens to bother or frighten them. ![]() How many different answers do you get? Three? Four? Seven?Įverybody associates the term with a feeling-frustration, usually-but they don’t have a precise idea of where that feeling comes from. How? We try to get businesspeople, designers, product managers, and engineers onto the same page by using the phrase “tech debt.” But that phrase puts us on completely different pages.Īsk someone in tech if they’ve heard of tech debt, and they’re likely to respond with a knowing sigh. We have no idea how to even get the business to consider that.ĭoes this sound familiar? It’s a disheartening conversation.īut we often predispose ourselves to this situation. Every feature release will feel like this until we get a few weeks to dig ourselves out of tech debt. A third needed to spelunk a long-abandoned repository to initiate the database changes. Another got stuck reorganizing the feature flags. One developer got caught in a framework update. We were supposed to release this feature three weeks ago. ![]()
0 Comments
Leave a Reply. |