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

I think this point is very under appreciated, thanks for pointing it out.

Along with the 'feature' that could kill things faster is general bloat when people keep building without knowing what the customer wants. You have to try something, but product testing should be done in such a modular way that most things can be removed if it turns out to be the wrong direction. Of course, you need a base data structure, but features should conform to that rather than constantly extend.

One example I'm seeing with a start-up I currently know is that they are building SDKs for multiple languages. Most of the code is auto-generated, but just the time in examples, documentation and packaging is killing them while they don't have customers for most of the languages they're publishing. This isn't just 'code' debt, there is overhead in documentation and management of code.

Unit tests just make the mess a bit easier to solve, but are far from a perfect solution. Wanna move and rename a function? Do it, then spend hours fixing your 10 broken tests, writing new ones, and test you app for hours because unit test dont cover integration. A static language + an IDE does it automatically within seconds.

I guess you could say this is a form of technical debt, or technical stubbornness.

I used to work for a company that specialized in Solar Panel data. I was hired to help the company catch up on their client queue (those waiting for the product to be set up).. and when I first started they were behind by about 140 clients and I had gotten the client queue down to about 30 clients remaining.

So our company would sell solar panels to corporations, and then they would put kiosks in the lobbys of their buildings so their clients could come take a look at the energy savings and other information about the building. It was a very popular way of doing things, especially in cities like New York, Chicago, and Los Angeles. Well, my job was actually designing the graphics for what was displayed on those kiosks and then syncing the data with the graphics.

There was a platform that did the work, but I still had to design the graphics and type in all the serial and model numbers and all that to sync everything together and make it show it in chart form in a gorgeous view. Anyways, for years, it was being done in Flash. Unfortunately, as progressive and dominant as our company was -- at one time, their technology was the best, even having received several awards. Over the years, HTML5, JSON, and other technologies were better and faster -- and could read data from a database just like as our system could, but turnaround time for production was faster for others. It took about 1 week for us to develop, set up, and sync everything from system to database. Now these other companies were able to get everything done in days, rather than a week or more. I think a huge part of the problem was my company had these corporations interested but forgot to hire enough people to actually do the work.

We did have an in-house software developer working on improving this technology, upgrading the software, but they seemed very reluctant to adapt the new software quickly. I had worked in the new software for a few days, and then all of a sudden, they called me into an office, and laid me off. A few months later, everyone else followed, and today, I think the company only holds on to about 2 or 3 employees who just maintain all the kiosks and software because of the existing contracts. Or maybe they went under... their website doesn't even work anymore.

Why did they go under? We were warned that technology was changing fast and that we needed to do something about it... and it was just the reluctance of the CEO to adapt the technology and push it out faster. Our competition slaughtered us. Luckily, it was my second job, so I worked out a great deal with them on letting me go.. I got about a month of vacation time on the condition that I wouldn't go file for unemployment. Obviously, already having another job, it worked out in my favor.

> it's quite likely I think they would simply switch to DC for everything

I'm not sure. AC has some important safety considerations that would make it better even if the efficient was significantly worse.

Switches, fuses and circuit breakers that work with DC are more expensive than AC. When a circuit opens there is a spark, and this spark can in some cases create a conductive plasma. With AC the wave goes to zero and the plasma disappears, while with DC it continues. There are cases where a DC fuse blew but the fuse continued to conduct. Of course this can be engineered around, but generally with larger and more expensive parts.

When someone touches power accidentally, AC is slightly safer. With DC your muscles will grab and never let go. AC gives you a chance to let go. This is a low probability thing, but is a factor.

The guy who wanted us to debate is wrong for one other reason though: I'm approaching the limits of what I know on the subject, while you seem to have a lot more knowledge.

I think we're going off on a tangent here, but even with that definition from Wikipedia, there's no such thing as "the best overall solution". Everyone is going to disagree about that; the best you'll get is a consensus. For instance, back to LaTeX, there's countless academics out there who use TeX/LaTeX/whateverTeX for writing academic papers, and getting beautiful results while not having to mess around with a WYSIWYG editor like MS Word and just typing in some simple formatting codes. That's what *TeX was designed for and has worked well for for ages. But I'm sure you'll find a few people who say this is bad because it's "old" and that they should switch to the latest MS Word for everything, and rewrite all their papers in the latest MS Word. If you look really hard, you might even find someone who thinks both are bad, and that all academics should rewrite everything in WordStar.

"The best overall solution" is up for debate. It's the same with programming languages; one team will say that C is the best overall solution for a certain problem, another team will say it's Python, another team will say it's one of the .NET languages. I'm sure you can find plenty of engineers who will claim that mission-critical real-time avionics systems or automotive ABS controllers should be redesigned to use x86 CPUs and run Windows and have the code written in C# instead of using C/C++ and running on a small RTOS on an embedded microcontroller.

The implication I see with your Wikipedia definition is that implementing something easy in the short run instead of something that really is the best overall solution will eventually lead to more work to fix the shortcomings of the quick-n-easy solution. So, like I said before, a "debt", because it has to be paid back eventually (with work). The problem I see is that not everyone agrees on what is the best overall solution, and unlike a money debt that's easily seen by looking at a dollar figure, the only way to really know how much "tech debt" you have is through experience, i.e. accumulating it and then finding out over time how much work you have to expend to fix things when your quick-n-easy solutions start having real, demonstrable problems. If your solution has no actual, demonstrable problem (e.g., you use LaTeX and it continues working great year after year for your use-case), then I don't consider that to be "tech debt" at all, even if some people don't like it.