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

271–280 of 331 posts

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

#271

Post by jrs235 »

cthulhubot wrote: post #258
jrs235 wrote: post #175

Earlier quoted context omitted.

Companies that think they are a product shop but chase enterprise customers and do professional services often fall to appropriately charge enough for their services. Enterprise level customers require not only more features, more guarantees, and more support, then require more attention. Are you appropriately including sales time and expense chasing them to get a contract as well as support resources into your CAC?…

This is a frighteningly accurate description of the company I'm currently at. They spent many years chasing after the enterprise level customers at the cost of alienating their smaller team level users and never had an answer when requests would crop up from the larger accounts asking for features ('just get it done'). Now they're trying to pivot back to the team level customers and are having an supremely difficult…

What industry are you in or where is the home office located?

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

#272

Post by edblarney »

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

"They did it that way because they knew stuff I don't know".

Or "They did what they did because they were the first one's to do it, and it only looks whack in hindsight"

Or "They did what they did because they were living within totally different constraints - like having to support old crap browsers like ie9, or a 'lowest common denominator' of slow end-user PCs etc., or some old chipset on the firmware code they wrote, or some old language paradigm, old libraries etc."

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

#273

Post by corecoder »

lacampbell wrote: post #205
beat wrote: 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.

I've been there a few times, and the worst thing is when every five or ten WTFs there's something that seems as ill thought as the previous couple similar blocks, except this time it actually makes sense, as it implements (awkwardly of course) some important corner case.

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

#274

Post by edblarney »

misja111 wrote: post #13

It happened to me twice. The first time was in a start-up at the beginning of the century, we were developing an electronic health record and we had outsourced the database abstraction layer to a company in Greece. In the beginning things went fine but after a while the development of the DAL went slower and slower and it became unstable as well. Eventually the word came out: the main developer of the DAL framework h…

"Eventually the word came out: the main developer of the DAL framework had left the company and, according to the Greek CEO, she had been 'too smart' which meant that nobody understood her code."

OMG no - run for the hills.

95% of software systems are not inherently sophisticated - they are 'complex' - yes - maybe there are many features, and moving parts - but there are no pieces of the system that should be hard to understand by anyone. Decent architecture + decent design and coding and an entire banks system should read like a long, but well articulated user manual.

Unless you're doing super low-level stuff, complex algorithms, heavy math stuff, or issues with massive scale or performance etc. ... the end result should almost be mundane in most cases.

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

#275

Post by contingencies »

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…

Yep.

mysterious and unsolvable breakage: Helping another startup work through one now. It's a case of reclaiming functionality from a mystery outsourced codebase (without source control) meets inexperienced developers who try their hand at sysadmin plus a 100% rotated bevy of actors (the whole team, PM and all, have jumped ship), no documentation and no technical oversight. Offshore outsourcing adds cultural fun.

unpleasantness: I would expand this to unpleasant or incomprehensible. I have seen projects be de-resourced because of lack of management comprehension when they literally paved the best and most rapid path to profit (later taken successfully by the now-dominant competition).

antiquation: The best example of this I've seen was a hardware product an employer was developing as a joint venture in Taiwan early in my career. Engineers had made the decision to use a sucky chipset from a struggling company to save money, but the supplier went under and the API froze (bugs, missing functionality and all) before our product development could complete. The target feature set was literally impossible to implement on the hardware and nobody wanted ownership. Many millions of USD, wasted.

replacement: It can work out, just infrequently. Generally when it works it's a smaller system with well defined interfaces.

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

#276

Post by Humdeee »

jfrisby wrote: post #235

I had a chance to ship the first Tower Defense game for iOS. The OS X game I was porting had some crippling performance problems that were incredibly hard to track down. The problem was two-fold: 1. The relevant tools (Unity3D) were extremely immature and the problem was quite diffuse. No profiler, poor quality of generated code, tiny caches, etc. 2. A problem in string-handling code that was quite diffuse throughout…

Wow. I'm actually seriously considering starting something on a smaller scale (tower defense for mobile as well) in the next few days as my next long-term(ish) side-project. I've done native iOS and Android for a few years now, but nothing with Unity as of yet. I know C# well enough. Other than what you've mentioned, do you have any immediate tips before I fall face first?

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

#277

Post by jsymolon »

agentultra wrote: post #142

I wouldn't say, killed , but severely burdened? Limited by technical debt? Sure. One application was a web application built in C++ in the 90's. It didn't have the STL, it implemented everything from XML parsing to PDF rendering from scratch. It stored all data in XML files on the file system. It was a single-threaded CGI application. And it was the core product of the small business that created it. There was no ser…

Highly Recommend Michael Feathers' book

"Working Effectively with Legacy Code"

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

#278

Post by bbcbasic »

pslam wrote: post #245

How about: All Of Them Every failed product/project I've worked on in my professional career, which had full intent to ship from the start, was killed by technical debt. It's usually indirect, but it's always the root cause. It takes many forms: * Too buggy to ship, due to a creaky old code base being over-stretched to a product with too high reliability/experience expectations. * Product form factor, efficiency, use…

Ironically you avoid technical debt by slowly killing and rebirthing parts of your product.

The class that is no longer appropriate for new requirements gets canned for a better abstraction etc.

In aggregate, over time, you may kill the product to avoid technical debt!

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

#280

Post by johnnyhillbilly »

Bartweiss wrote: post #217
pavel_lishin wrote: post #132

Earlier quoted context omitted.

"Let us use our logo" doesn't seem like an unreasonable request.

And it wasn't! That was part of the problem: the sales people couldn't push back on most requests because they were often quite reasonable. When they were more demanding, it was usually from a large prospective buyer so we had to bend over backwards. The result was that we had huge tasks to do with no (current) revenue, and small tasks to do that took 10x as long as they should have. Since servicing existing revenue…

Sounds like you needed better sales people.
Post reply on HN