Live data from Hacker News

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

news.ycombinator.com

291–300 of 331 posts

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

#291
post #183

Earlier quoted context omitted.

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…

I recall seeing IEEE articles talking about the DC wired home. I confess I stopped paying attention, as it will be a long time before this is actionable for me. Can't claim surprise to know that I had things that were wrong.

Of course, the cynic (and, ironically optimist) in me still has this as evidence that "technical debt" is often used in BS circumstances by people that just don't fully understand the reasons for the things they are talking about. :)

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

#292

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…

>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. That's orthogonal. What you really mean is that you want high(ish) voltage to distribute power in a home, in order to mimimize losses due to wire resistance over distances of dozens of meters. You don't need AC to do that. In fact, with modern power electronics, the switching converte…

I'd be interested in you two debating this more, since you both clearly know the topic better than I do. This post is reflecting what I thought I had heard. But, I am not in this field.

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

#293

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…

Last company I worked for did that to great success. All our customer got a custom version of our product tailored to their needs and their project. At least half our customers where doing something that needed at least one new feature that we didn't currently have. If you build your business model around that it is not necessarily a problematic model.

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

#294
post #188

Earlier quoted context omitted.

"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".

There's obviously a lot of stuff I don't know then. Like the benefits of copy pasted code, or 300 column lines, or implementing the logic in 20 places when it has existed in the standard library for a decade. If only the ancient sage I inherited this code base from had left notes to guide me on this path of wisdom.

Copy-pasted code: Data redundancy

300 column lines: Support for management buying everyone nice, new, giant monitors.

Logic in 20 places: But what if we want subtle differences between each implementation?

On a more serious note, a product that I've worked on was started in about 1998 in C++. We support something like 15 different platforms, and we've got our own implementations of things like vectors because we needed a least common denominator codebase; the standard libraries of a lot of platforms didn't provide what we needed, or provided implementations that were incompatible with other platforms. By the time everything we needed to support was modern enough (in about 2010), the system had a few million lines of code, and replacing things with library functions/classes would've been a nightmare. New development is saner, but the legacy stuff is entrenched.

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

#295

Our product, a large-scale enterprise software, is slowly getting killed. It's old and it's rather unusable (by the users). Plus, for "backward compatibility", it supports dozens of strange configurations. It's dragged down by so much technical debt (functions longer than 3000 lines with 60 parameters!) that every small changes requires so much time. We're slowly killing (i.e. no big new developments, but only mainte…

Functions with 60 parameters. Jesus Christ....

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

#296

Earlier quoted context omitted.

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…

It's a great idea but in reality most third-party tools are going to work slightly differently and the abstractions will leak (unless they were developed against an existing interface, in which case you don't need to create the wrappers yourself anyway).

I think the optimal route is to not bother with (extra) abstractions and interfaces, but try to avoid using things that is unreasonably tied to vendor - unless you save a lot of time.

If the code base is not a pile of dung anyway, the cost of find/replacing and refactoring obsolete or replaced api:s once is so much smaller than the running costs of maintaining an extra layer of leaky abstractions for many years.

It is guaranteed that the abstraction will not work without a lot of changes anyway, and what typically takes the most time is the regression testing.

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

#297
I have many times taken over projects that were so deep in technical debt that only extreme surgery would save it from being killed. It can take a long time to turn those projects around and make them healthy again but it is possible.

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

#298

I have many times taken over projects that were so deep in technical debt that only extreme surgery would save it from being killed. It can take a long time to turn those projects around and make them healthy again but it is possible.

The first step for me is always to add solid tests. On one project (for example) it took 8000+ test cases to make it solid, maintainable, and bug free in production.

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

#299
post #238

Earlier quoted context omitted.

Yeah, that. But even things like cvs, that were modern and hip in 1998, are still floating around 20 years later. I actually thought Subversion would be the last version control system, when it came out. Of course, now it's git. Maybe someday we'll get something better, and git will look decrepit.

I have little doubt that git will be replaced eventually (or perhaps severely modified). It seems like a fad to me. It is indeed very powerful, but its UI is sheer insanity. At least SVN is very straightforward to use and understand. It just doesn't offer the distributed nature that git does, as it relies on a centralized server.

What UI? Using git on the command line is exactly the same as using SVN on the command line. At least for basic, every day things like status, add, commit etc.

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

#300
post #292

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. That's orthogonal. What you really mean is that you want high(ish) voltage to distribute power in a home, in order to mimimize losses due to wire resistance over distances of dozens of meters. You don't need AC to do that. In fact, with modern power electronics, the switching converte…

I'd be interested in you two debating this more, since you both clearly know the topic better than I do. This post is reflecting what I thought I had heard. But, I am not in this field.

There's really nothing to debate; the guy I replied to was totally correct about everything except the bit about "AC is much better in the home", where I pointed out that he really meant that a high voltage roughly where our current AC systems are (120V-240V) is much better in the home than some kind of low-voltage DC system, and that with modern technology, it would probably actually be better to have a DC system. But realistically, that's not going to happen because the gains (probably very minimal) aren't worthwhile compared to the enormous cost of conversion, given how standardized our current AC system is and how all our infrastructure, point-of-use devices, etc. are all designed around that.

Basically, he was assuming practical real-world considerations, I'm going off on a tangent about ideal conditions. His argument is about whether it's better to stick with the current AC system that your house has, or if it's better to install a low-voltage DC system to supply 5V, 12V, etc. to all your devices from a single, central, whole-house power supply as many people who don't understand electricity will frequently suggest. He's completely correct: low-voltage DC is a terrible way to supply power over any distance more than a meter or two because of resistive losses, so it'd require massively large copper cables or busbars. And power supplies are generally very low-efficiency when operated at low load. So our current approach (separate little optimized power supplies for every device, plugged into a higher-voltage AC supply) is actually optimal.

Post reply on HN