[k__]

Usually, the discussion goes the other way around.

Product is pissed because delivery is stagnated and that's because of technical debt.

Product: We need that change for Big Co.

Techie: Okay, that takes two weeks.

Product: Two weeks? For such a small change??

Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence.

Also, usually techies don't care.

Why? Because it's always good to have an excuse to work slower.

[drcongo]

Yeah, I didn't find the intro conversation in the article familiar at all. And also, if a one day change is taking a week then when asked "Oh really! What is it costing us?" the answer is 5x what it should. It's incredibly easy to directly link technical debt to running costs.

[perrygeo]

Exactly this. The author's dev-blaming perspective is that Tech Debt costs are not accounted for systematically nor communicated clearly to the business folks.

Yet the intro provides an example of clearly quantifying and communicating the costs. I'd say he disproves his own point in the introduction. I found it hard to read the rest of this article.

[andrew_]

> Why? Because it's always good to have an excuse to work slower.

Oof. What's better is setting and going by your own pace and making sure you're projecting expectations with regard to that pace.

[willis936]

Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not interesting.

[matthewmacleod]

I don't think I've ever worked in an environment where the tech team would have resisted the opportunity to take some time to refactor or update some systems that needed attention. In fact, they'd most likely be overjoyed and would much rather do this than implement features. YMMV from team to team, though.

[thinkharderdev]

I agree. I think people on HN generally underestimate the extent to which developers themselves push to work on new features instead of maintenance. It's often a different kind of feature though. I can't count how many times in my career devs (including me!) instantly jumped to "we need to rewrite X using new framework Y" in response to technical debt in X.

[k__]

I only saw that behavior in younger devs.

The average dev just does their job. Same as with the average person in every industry.

Sure, it's nice to do a cool feature, but most people don't work at interesting projects to start with, and they simply have to churn on. There isn't much difference between a new feature or maintenance in boring projects.

[drcongo]

I _love_ maintenance and fixing technical debt, much more than working on features.

[fendy3002]

And it's easier though if you have different skillset than feature development.

Essentially the features, flows and output are fixed and defined, so you don't need to think about that. Your skills at performance optimization, refactoring, unit testing and debugging really shines here.