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

221–230 of 331 posts

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

#221

Post by CydeWeys »

taeric wrote: post #183
bluGill wrote: post #162

Earlier quoted context omitted.

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 efficien…

Including light bulbs?

Yes, even light bulbs. A typical household LED is very easy to run off AC. You just need a capacitor big enough to hold the charge between each cycle of AC (which is very little). More information here: http://www.ledsmagazine.com/articles/2006/05/running-leds-fr...

It'd be vastly more expensive to wire up an entire house for low voltage DC than it is to include the simple rectification components in every light bulb. In a house you're talking about many wire runs of many dozens of meters. This is not a good environment for low voltage DC at all.

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

#222

Post by zzzcpan »

wvenable wrote: post #181
zzzcpan wrote: post #180

It's a good question, because all software has "technical debt". Which means "technical debt" is not a real thing, but a concept invented out of a limited understanding of the problem. Instead, there is always a tension between a simple solution and a more flexible one and there is always a way to make things simpler or more flexible or even more complex and less flexible. For many problems the key to keep both simpl…

I disagree with your definition of technical debt. Decoupling everything as much as possible may be good (or it may over complicate the problem) but technical debt occurs when you don't do things like that, whatever you define as the "proper way", for sake of expedience or lack of experience. All software has some technical debt but you can have more or less depending on how much effort you or your organization takes…

> but technical debt occurs when you don't do things like that

When you don't do things like that you may or may not simply weaken your flexibility or/and simplicity. It doesn't mean that it's a bad thing or a debt, because you have no idea whether you you may need any of that later. Long-term software projects, for example, might benefit from DSLs so much more, than solving those problems on a lower level with all the decoupling and everything, is it a debt then? Absolutely unclear. Because it's all about productivity and risks and all of the non-measurable things.

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

#223

Post by ScottBurson »

beat wrote: post #188
mywacaday wrote: post #178

Earlier quoted context omitted.

I've learned over time that its always better to assume that who came before me were smarter than me and knew more than me (I'm rarely proved wrong).

"They did it that way because they where stupid" is a ridiculously common assumption, when the correct answer is often "They did it that way because they knew stuff I don't know".

Well, I think one has to be alert to both possibilities.

This is perhaps a subtle and underappreciated reason that code quality is so important. If you're looking at an obviously well-written piece of code and you see something you don't understand, you can figure it's probably there for a good reason. If the code has visible sloppiness, it's much more difficult to tease apart the good parts from the bad.

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

#224

Post by krmboya »

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…

Would these be cases where Robert Martin's 'The Clean Architecture' [1] would help, where the core enterprise logic is separated from third party dependencies, making the latter easy to swap out and replace?

I'd imagine a number of these cases are caused by a heavy reliance on third party technologies that are no longer supported, or very few people still understand.

[1] https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-arc...

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

#225

Post by Arizhel »

beat wrote: post #128
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 should add here that the "antiquation" case is the one that has caused the most observed grief in my career. The forces causing failure are coming from outside the code/business (dependence on an outside vendor), and sometimes collide with forward momentum of other parts of the code (i.e. that graph library will never, ever work with Java 7, to name an example). These become life-or-death situations, and the tendri…

>You can still find teams dependent on an antique commercial version control system or IDE that greatly slows down or even stops work.

Sounds like Rational ClearCase.

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

#226

Post by luhn »

ardivekar wrote: post #220
RangerScience wrote: post #209

Earlier quoted context omitted.

Yet another reason I swear by Heroku - you can rollback to the actual prior release, not rollback the code and try to rebuild.

Doesn't AWS do this too?

Depends on which of their 150 services you're talking about. You can't do it on CodeDeploy.

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

#227

Post by st3v3r »

CydeWeys wrote: post #88
taeric wrote: post #80

Earlier quoted context omitted.

This sounds less like technical debt, and more like liabilities of over engineering. Possibly feature creep. That is, technical debt is not necessarily tangled over-engineered code. It is more compromises that were made to actually ship and operate in the world. You can see this in the world with devices. Consider, technical debt is the reason you have AC delivered to your house going through as many converters as yo…

> Consider, technical debt is the reason you have AC delivered to your house going through as many converters as you do devices. Often to the same target power characteristics for those devices. Bad example. AC power has many desirable characteristics for the local transmission grid. If you were to do the grid over from scratch you'd still use AC. You're also too focused on household electronic usage, which is a very…

It's just an illustrative example. And I'm going to bet that most of us, the vast majority of us, really only have experience with household usage. So it would make no sense to get into other usages, which most people won't understand.

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

#228

Post by always_good »

samwilliams wrote: post #143
pizza234 wrote: post #134

Earlier quoted context omitted.

CSV is trivial? You may have missed this: http://tburette.github.io/blog/2014/05/25/so-you-want-to-write-your-own-CSV-code/ :-)

This is interesting, and as the other commenters have pointed out, creating a parser for /all/ variations of CSV can be very tricky.

But your code doesn't even handle the trivial case.

    "She said, \"Hello, world!\""
You can drop the "meh, I know I didn't handle all the complicated cases" act.

We all recognize the classic developer I-could-build-that-in-a-weekend hubris when we see it. :)

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

#230

Post by moomin »

How about an entire company?

I worked for a dotcom back in the day. The underlying tech was appalling, to the extent they couldn't actually stay on the internet. We fixed this. They then proceeded to vastly expand the site, but every part of it was written as a special snowflake.

Five years later, they decided on a rebrand. This was literally a reskinning of the existing site. It took 50 odd people, ten months and more overtime than you care to think about. Many of those people were contractors.

Not only was this a huge expense, it prevented us from making the site any better. It was an extremely competitive market and the other sites ate our lunch. The next year was to be after round of redundancy, a financial statement that wrote the value of the business down to its cash reserves and finally a sell-off.

Ironically, the new owners turned it back into a viable business, but they had a very different attitude to technical debt.

Post reply on HN