Hacker News Reader

I think that may companies need a fundamental shift in managerial culture before they take technical debt even remotely seriously.

The only way I've ever managed to do anything about technical debt was by hiding the fact that I was doing it - since it was completely impossible to get any level of managerial buy in or even permission.

It shouldn't have had to be that way, I should've had higher level support, other developers to work with and competent testers - working in that situation ultimately left me never wanting to write software for anyone else ever again.

It's a disease of reckless incompetence, and it permeates the managerial structures of large swathes of the software development industry.

Same here, I'd always pay off a little debt here and there and the busy-waiters would be circling my desk asking for status -- from the busy body product owners to the nitpicking directors at their weekly inquisitions, there's a whole class of parasites whose only contribution is to trumpet how late we are and insist on asking 'how long will this take?'

I got it too the point where the standard changes took a fraction of the time to implement compared to what it would've been operating on the initial code base.

In fact, some of the functionality that I ultimately implemented would not simply have taken longer, it would have been impossible to implement without introducing world ending bugs.

None of that mattered. Nothing that I ever said or did in that place meant a fucking thing to anyone.

Where have you been all my life bro! Nobody gets it any more -- precisely the attitude needed in this industry; we need to turn the tables and take our craft back in-house

How's that meaningfully different than performance and code cleanup cases? Frequently, a team know how to implement a feature in an efficient manner, but only has time for a low-performance hack job. Similarly, "code cleanup" is as much a code word for "not how I would have done it" as it is for "bad architecture that will start constraining us very soon".

Performance work is no different than new features: requirements change.

Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment.

When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.

Cleanup is not about how the code works at runtime, but how well it supports change. An abstraction that looked right at the time shows its cracks years later. Changes that should be simple and low-risk become intense and scary when they need to fit in with it.

It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0.

Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team.

The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.

> Cleanup is not about how the code works at runtime, but how well it supports change.

This. A thousand times, this.

> That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment.

I'm thinking of cases where it was a conscious choice. $deity knows that I've made plenty of such decisions in my career - chosing a hacky structure A to meet a next month's release, while articulating to management that after that release, I'll need to redo it to structure B. Sometimes a bunch of high-priority requests took precedence, which made the system stick to A for far longer than it should. I understand that to qualify as both "technical debt" and "architectural issue".

I'm confident that each and every one of us (even in the open-source world) can say "been there, done that".

I use code cleanup as a term very differently, as a programmer with 20 years commercially developing software..

My process often involves creating layers/versions of the code that improve till the stage it's production ready. It might be half a dozen or more iterations to get to production quality for complex code, and the latter versions involve a lot of 'code cleanup'!

This includes things like implementing TODOS, adding logging, and refactoring and refining the concepts, the naming, making the code more dry, better srp and generally elegant code I hope that someone else would be happy to inherit and maintain and extend. That someone is often me!

It's taking something that works, mostly, but has limited clarity and elegance and higher future costs to work with, and 'cleaning it up'. Like a home or worksite cleaning up after working gets you ready to use it or work there productively in future.

I do this in most codebases I work in for awhile as well, when there's clearly need for improvements in dry, srp, conceptual patterns and clarity.

Our industry jargon calls this refactoring, but cleaning up actually relates to other stakeholders than the highly trained engineers, so I will generally call it cleaning up.

I agree with you that newer engineers often want to rewrite existing working things for many wrong reasons - but I think the specific term code cleanup has a place.

I think it's interesting that you've noted it as a code smell for a junior about to wreck a significant amount of company productivity. That's an all too common problem these days as the majority of engineers are junior with less than 5 to 10 years due to larger numbers entering the industry. I'm interested in the 'successful' strategies experienced engineers have used to head this off at the pass in organisations with non technical management who often listen to the loudest voices if they can't truly understand the issues themselves.

>> "That's possible, but a bad argument. And it's insulting."

Firstly, there are people smarter than me, it's not insulting, especially if a person makes a real improvement. Or maybe I made a mistake.

Secondly, original designer had to make a decision with limited information and time. Now we have the benefit of hindsight, so coming up with a better one is hardly surprising.

> And it's insulting.

It can be in certain cases, but it sometimes depends on the perspective. Abstractions are hard and usually need enough time to think about and several iterations to get right. They are usually much more obvious in hindsight.

Because "performance" is not related to "functionality". If you skip corners (eg. panic instead properly forwarding an error, hack a new implementation over an existing interface, etc), you induce a long term cost each time you have to figure out why the code is misbehaving.

Technical debt is all these architectural issues which incurs a long term cost because minimum deliverables had to be met. Also, the first response to "performance" is always gonna be "throw more CPU/memory", not "let spend a month dev-time to rearchitecture." Tech-debt is only getting addressed when hardware can't meet the requirement, "performance" is just a marketing argument to sell it to management.

Making code perform more efficient is easily analyzed as a feature. If the inefficiency results in end user delays then it can be directly traded-off against other feature requests, if it only impacts costs it can be fairly easily be determined whether or not it is worth devoting (very expensive) developer resources against.

Prioritizing improving performance for aesthetic reasons, that is because a "low-performance hack job" offends someone's sensibilities, likely means either: 1) the team is poorly lead or 2) doesn't have enough high value work to do.

Debt can also be taken on accidentally. You can build a couple of features one way and expect future features to be similar, but then reality bites and the way you've built them makes the next feature that happens to come along harder, and the next, and the next. Or the way you've built them doesn't allow for the rate of change in that area - something in code wants to be in config, or something in config wants to be in a CMS. In the debt analogy, it's like having a variable interest rate: you can make a decision which is correct for today's conditions, but the market moves and you're paying twice the interest and suddenly it doesn't make sense any more.

I’m dubious of defining technical debt merely as the result of previous decisions taken to trade off delivery time for maintainability. That’s the responsible form of technical debt and responsible people will incur it. But there are irresponsible forms of technical debt just as there are irresponsible forms of financial debt. What makes something technical debt is the “interest” in terms of maintainability that one pays for it.

To make the term more useful to me I like to extend the analogy and think in terms of interest paid on technical debt.

So you took a shortcut because of pressure to ship but now you’re spending loads more time providing tech support. That’s the interest you’re paying on the technical debt.

So in terms of choosing what technical debt to pay off first consider which ones have the highest interest payments. And remember that like financial debt, technical debt also sometimes comes with introductory interest free periods.

Yes, it's extremely strange that people are looking for new terminology because they've been using the existing, perfectly good, terminology incorrectly.

> Always pay down technical debt when you can. It will be paid eventually, it's just a question of how painful it will be when you do.

Not really

I have a program which is a right pain, and takes an hour to do a yearly task. To clean it up would take about 200 hours.

The program is unlikely to be around in 20 years time, let alone 200.

Your third example is just some combination of the first two. Performance issues: the efficient solution is too complex, we don't have time. Code cleanup: this is not the way I would've done it if I had more time. The debt metaphor fits so well because you're borrowing time.