Hacker News Reader

Comment by mobjack | Hacker News Reader

I distrust my fellow software engineers when they say they need time to pay tech debt.

There were many times where I refactored code that never received any additional updates or to have the feature removed. I wasted a lot of time without any real gain for it.

There are real costs to paying off tech debt and it is easy for engineers to spend their time on low value refactoring.

Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there.

If you can show you can prioritize business value then it is easier to convince management to give you two weeks to clean up tech debt.

View on HN

> There were many times where I refactored code that never received any additional updates or to have the feature removed.

Since we're throwing out anecdotes, I've lost count of the number of companies I've seen that were essentially zombies due to technical debt. They had aging, rotting codebases that were impossible to add features to at the rate needed to continue making sales. No senior engineers who could improve the situation wanted to set their careers back by working for them.

I think you and grandparent post's author are both right. I've seen both. It depends on the type of engineers that inhabit your team, and therefore are not mutually exclusive.

The main problem is that many developers will increase technical debt when they try to fix it. For example, some will try to fix technical debt by writing a new framework. Then the new framework doesn't handle all edge cases, so you still need the old solution. Now you have two different conflicting styles creating more technical debt. The next developer will come in, see the mess, and promptly start working on a framework to consolidate everything...

So whenever you consider fixing technical debt, ask yourself if the team is skilled enough to actually create a cleaner solution. If they can't then it is just a waste of time. The best predictor of this is that they have created a cleaner solution elsewhere, if they haven't then don't let them work on technical debt unless they have an extremely well thought out plan.

Management's solution is often to hire more software engineers.

Ironically in big corporations I think that this actually plays into their underlying desires - giving a boost to headcount gives them more importance and having more developers means that the leverage each engineer has is commensurately less.

I've worked on more than a few projects which would have proceeded 4x faster with 2 good developers on a clean code base than the 7 they actually had.

Indeed the entire software startup industry is probably reliant upon this dynamic.

Not the software startup industry, unless you're flush in easy VC cash. Most of the startups which are trying to solve real problems that I've known/interviewed for are extremely conservative with hiring, for the very good reason that bad hires are not just a 0 value add, then can be a negative value add.

Uber is one of the outliers in this regard. But if you look at most successful others (Instagram, Whatsapp and a bunch of others I don't want to name since I want to stay anonymous) all had very small teams right until they were acquired.

I meant that the startup industry would be hollowed out if large corps didn't exhibit this dysfunction and thus create space in the market for them, not that startups do it themselves (although occasionally they do too).

Ah, that does makes sense. Apologies for misunderstanding.

My experience is that these companies have the worst kind of technical debt: a prematurely optimised and poorly abstracted codebase, due to non senior engineers refactoring just in case. Non abstracted codebases are boring to work with because the same code is duplicated, but they are not that difficult to change or add feature to. Extreme DRY on the other hand are the kind of codebase everyone is afraid to touch. Sure maybe they had 100% test coverage in their days, too bad adding a new feature with a small model change would break every interwined object factory.

It's not just extremely DRY stuff that can be problematic.

I work in a non-abstracted code base, but all that really means is every time someone wanted to do something they simply wrote their own way of doing it. Needless to say it's suboptimal to work in on the best of days.

People like to deride one way of doing things vs another but in reality pretty much every approach to software development and architecture can be amazing or hellish depending on the aggregate quality of the developers, their management and the lines of communication between them.

TL;DR - Bad code is bad no matter the paradigm and all paradigms can be made awful.

> Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there.

This.

Software engineers are focused on the implementation side of things and how today's work will impact their work in the future. Yet, sometimes a quick and dirty solution that takes close to nothing to implement is more than enough to put a functionality in production. Sure, the whole thing will need to be scrapped in the near future when rewriting the feature to meet all design requirements, naturally the quick and dirty solution underperforms, and of course implementing it properly will take 3 or 5x the time. Isn't it obvious that the team is wasting it's time by implementing a quick and dirty solution?

Yet, the quick and dirty feature does shorten the time to market to a fraction of what it would otherwise take to implement properly, and perhaps that is good enough for the project for the time being.

It's for this reason that I've often tried to get the business side to give opinions on how shoddy/quickly they'd like the feature to be done. Curiously a lot of the time they appear very reluctant to do so. It's probably CYA kicking in maybe... many managers don't like to say "do a shoddy job" if it ends up biting them in the ass later... they'd often rather just hint and exert unspoken pressure to rush it out and then deny everything later when the CEO starts asking questions a bug that fucked everything up.

There are exceptions, of course, and I'm pretty happy to have worked with them, but in general about 90% of managers I've worked with have resisted my attempts to get them to be explicit about the level of quality that they want.

Quality is so ridiculously subjective that I'm not sure a non-technical manager should approach the question, and a technical manager should refuse a direct answer and steer the conversation towards structure and deliverables.

% of time spent on refactoring is completely objective. Whether that results in quality is another matter, but it's a dial that a product manager has control over that (usually) has direct impact on the quality of the end product.

My take is that product managers care mostly about what functionalities were delivered and if the requirements are met. If the development teams deliver a quick and dirty solution and it meets some requirements then they check the requirement as delivered, and that's it.

When this happens then the devteam's negotiating position changes completely, because they are no longer arguing about how to allocate resources to deliver a functionality and instead they are asking to waste time rewriting something that was was already delivered and is supposed to be up and running.

Do you not consider overall product quality to be a product decision?

"Continuous attention to technical excellence and good design enhances agility."

Very few people seem to actually believe this in their bones. All talk about being "agile" and "pragmatic" becomes a joke when it's posed as somehow being in contradiction to design and anything that goes deeper than finding a place to insert your new if statement.

> If you can show you can prioritize business value then it is easier to convince management

If your management needs 'convincing' then there's a problem.

Either the manager is technical enough to know whether a particular set of work is the right thing to do or not, in which case they don't need convincing. Or they're not, in which case they should defer to the engineer and also not need convincing.

The only managers who need 'convincing' on technical matters are technically inept individuals who nonetheless attempt to micromanage technical decision making. They are no more able to link business value to technical decisions than the engineers you say you distrust. Fire them.

> Engineers don't generally enjoy paying off technical debt, it's a chore. But they recognise that it must be done sometimes.

I disagree. Most engineers I work with like refactoring. It’s usually well defined work with clear metrics for success. It can also reduce daily pain if it makes delicate/messy code much easier to work with.

The problem with refactoring is that its only value is in improved execution of future projects. So it can be extremely valuable or completely useless. It depends on how likely the refactored things are to be worked on again.

Reply on news.ycombinator.com