Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Have you ever worked on a product that was killed by technical debt?

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 331 posts

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#161

Post by ayuvar »

ryandrake wrote: post #107
Bartweiss wrote: post #93

Earlier quoted context omitted.

This is a great example of how technical debt 'kills'. It's not a murder, it's negligence and a slow demise. I went through one of these projects. The tech debt was never as bad as you describe, but it was a small company operating on a short runway. It also taught me an unfortunate lesson about non-technical founders and the dangers of outsourced code. The MVP for the company had been bought off the shelf. It worked…

Seen this a lot. A lot of companies think they are "product" companies, but due to their unwillingness to push back on customers, they become custom engineering shops, bolting on little one-off mods to their project over and over to appease bad customers (or to appease POTENTIAL customers who haven't even bought the product yet). Stop me when you recognize this one: "Hey your product is great, but we really want some…

I think every one of my former employers who have failed, did so by doing those 'customs.'

The last one even spun off a dedicated team that built (hacked) prototype customs in order to secure sales, then threw away the prototype and, after collecting the commission, told the new customers that it would take several years to get what they just saw in production but in the meantime we can do our existing product with some mods.

I imagine the pressure to accept these deals is immense though. Why let an innocuous little feature request hold up such a great deal?

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#162

Post by bluGill »

taeric wrote: post #118
napoleond wrote: post #110

Earlier quoted context omitted.

HVDC does have advantages in certain scenarios (very long transmission lines, for example) but parent is still correct--the majority of the grid makes way more sense with AC.

I meant my follow-on to be a concession, but worded it poorly. I thought it had advantages, but yes, I was thinking small appliance mainly. In particular, in home. And not just computers, but lights and control panels. Seems many things all use the same power characteristics and are now becoming complicated by dealing with AC. Which, amusingly, is fitting for the tech debt debate. Eradicating some choices from the pr…

AC is much better in the home. There is no way to get around the fact that you need massive wires to supply low voltage at high amps.

It is much cheaper to have a power supply on every electronic device turning 100-200 volts to 5 volts than to have one big power supply turning power line voltage to 5 volts. Of course a lot of computers need 3 volts or less, so the power supplies exist anyway. It is also more efficient big power supplies running at low loads are inefficient, the power supply on each device is sized to what the device needs and so it more likely to be operating in a high efficiency area.

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#163

Post by jrs235 »

Bartweiss wrote: post #124
ryandrake wrote: post #107

Earlier quoted context omitted.

Seen this a lot. A lot of companies think they are "product" companies, but due to their unwillingness to push back on customers, they become custom engineering shops, bolting on little one-off mods to their project over and over to appease bad customers (or to appease POTENTIAL customers who haven't even bought the product yet). Stop me when you recognize this one: "Hey your product is great, but we really want some…

Ouch, that's almost word-for-word from the company that died of debt. It was enterprise sales, so customization was unavoidable, but no one was differentiating between big and small changes, or big and small buyers. The product was desperately struggling to do ~3 things at once, and still being sold to potential buyers on the promise of a fourth thing it would do "soon".

Enterprise customers which require enterprise sales require enterprise pricing. If appropriate enterprise pricing is not in place then you risk an enterprise failure.

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#164

Post by ayuvar »

Lewton wrote: post #52

The last place I worked at will die because it will take them years to migrate from Oracle to postgres due to "technical debt" (the codebase is coupled with the database to a hilarious degree; business logic in triggers, huge plsql packages, plain sql queries in the java codebase, halfassed homerolled ORM). They're not getting as many new customers as they could because, for various reasons, the Oracle licensing term…

I don't know if I've ever seen a successful database transition for a large project at a large firm. You basically have to build that from the start.

Doing it after the fact in a politics-heavy organization is confounded by not just the technical difficulty of the task, but the glad-handing and perception management that has to happen to keep your team from getting fired during the process.

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#165

Post by tluyben2 »

Definitely have 10+ years ago. The non technical partners (majority) thought no refactoring was needed until it was almost too late. Company still exists but had to pivot quite a bit.

More recently another one which is being killed by tech debt but the tech is so old that only a rewrite can really save it and the income from it is just not high enough to warrant it.

(the former was written by me at first before the company really took off and the latter was an acquisition)

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#166

Post by SideburnsOfDoom »

koolba wrote: post #157
beat wrote: post #109

There are multiple cases of "killed by technical debt". There's the case of mysterious and unsolvable breakage. The product simply stops working, and the team is unable to get it working again, period. This can happen with really ancient legacy products where the original team is gone, or young products that are written badly by inadequate teams. There's the case of unpleasantness. A product is so difficult and slow…

Some of the worst examples of that are when a project uses a custom build of a library of which the source no longer exists and no record of the changes exists either.

Yep, seen that. You might be thinking of tweaked builds of open-source components, but before package managers were so common, I've seen also internal projects with a `/lib` folder full of artefacts like `MiscDbUtils.dll` which are internal "useful" utility functions that are widely used.

Now add in a script that updates this artefact with the latest version, breaking changes, and it all goes wrong and it's hard to find the correct previous version of the binary artefact to build your code any more. Especially if the build has been broken for a while due to the project being on the back-burner and it quietly dies when no-one is looking.

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#168

Post by nsxwolf »

beat wrote: post #109

There are multiple cases of "killed by technical debt". There's the case of mysterious and unsolvable breakage. The product simply stops working, and the team is unable to get it working again, period. This can happen with really ancient legacy products where the original team is gone, or young products that are written badly by inadequate teams. There's the case of unpleasantness. A product is so difficult and slow…

I worked for a company that grew considerably for 10 years and then lost its biggest client and folded quickly. We had spent a few years reworking our platform in a way that might have been successful enough to weather the storm of losing that client, but technical debt really slowed us down.

Technical debt may not have killed the company directly, but we have to wonder how we might have done if we could have spent more of our time on new development.

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#169

Post by sbov »

misja111 wrote: post #76
olavgg wrote: post #72

Earlier quoted context omitted.

Could you not scale this horizontally? We do all template rendering server side, though it is JSP and not JSF.

That was considered but it would of course take some refactoring on the back end, and it would still cost quite much in hardware. The thing with JSP and JSF is, they do ok as long as your content is relatively static, because then rendered content can be cached. In case of this company, their most visited page was the list with search results which by its very nature was not very static at all.

Every problem is different, so I hate to judge, but what you're saying doesn't add up to any experience I've had.

It sounds like your company seriously screwed up the design if you can't scale your web tier code horizontally. I've also never had a view technology take up a significant chunk of cpu resources - it's always the Java code carrying out the functionality. E.g. I would expect the largest factor in CPU usage in the list of search results to be... generating the data for the search result. If the largest factor was rendering the result, then something was probably seriously wrong.

Re: Ask HN: Have you ever worked on a product that was killed by technical debt?

#170

Post by javajosh »

ayuvar wrote: post #158
koolba wrote: post #157

Earlier quoted context omitted.

Some of the worst examples of that are when a project uses a custom build of a library of which the source no longer exists and no record of the changes exists either.

Reintegrating future changes in the upstream is also made nearly impossible as a result; our tech lead made a change to numpy a few years ago, didn't manage to get it accepted by the project, and we're stuck with this version until the sun burns out. If there are changes in future numpy versions we want, it's up to us to backport them, which is nowhere near our core business. There's a lot to be said for standardizat…

Well you could estimate the impact of backing out of the changes on the application side, with the upside being continued savings in operational complexity. Or, you could address the operational complexity with processes or tooling - which would be easiest with something like a developer OS image.
Post reply on HN