Live data from Hacker News

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

news.ycombinator.com

21–30 of 331 posts

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

#21
post #2

I've worked in the industry as a developer for 12 years and I can't remember any. I do remember a competitor dying of not releasing their big refactored next version soon enough, and running out of cash. Spolski tells it better than me: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Same thing, back in the first dotcom boom. I think the company would have died anyway, but they burned whatever runway they had by undertaking a complete rewrite of a working ASP/SQL web app (full stack Microsoft). The new version was to run on Linux and use a variety of custom code, sourceforge and/or freshmeat projects, and several different data storage tiers. An explosion of architectural complexity. As far as I could tell the main reason was that the CTO and his top architects were all Unix zealots and hated Microsoft.

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

#22
post #2

I've worked in the industry as a developer for 12 years and I can't remember any. I do remember a competitor dying of not releasing their big refactored next version soon enough, and running out of cash. Spolski tells it better than me: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

The Firefox rewrite was a success by all measures. Spolsky is wrong on this one, at least with the claims of generality.

Except for one measure: Netscape died as a company. The huge rewrite contributed to killing it. If you don't ship a product (for like 4-6 years?) you're gonna die. Mozilla originally chose the name phoenix, (then firebird to avoid trademark problems, then finally firefox) was chosen because it was a phoenix rising from Netscape's ashes. Its major innovation: It was 'blazing fast' when compared to ie 5.5 / 6. Tabbed browsing was also pretty cool.

You can learn a lot of lessons from Netscape, but this isn't one of them. Servo is a great example of how a rewrite should / can work. Mozilla hasn't devoted 100% of resources to Servo, but instead is letting servo build all on its own, and someday unclearly defined in the future, the two could merge. (but might not!) It's a separate product, and nobody is pinning all their hopes and dreams on it.

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

#23
post #20
post #2

I've worked in the industry as a developer for 12 years and I can't remember any. I do remember a competitor dying of not releasing their big refactored next version soon enough, and running out of cash. Spolski tells it better than me: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

I'm a fan of continuous refactoring, making small improvements to code and environments constantly, rather than trying to do everything all at once. It might not be as satisfying, but it's less risky and a lot more realistic in most work environments.

The problem is when you need to change your "platform".

I worked on a 300k LOC business basic application at one point.

The big question everyone was asking is how do you move to something else? Everyone wanted something else, they started writing new services on top of the old system, they had some ideas on where to go, but it just didn't seem like a gradual rewrite was possible.

And to be honest, a Greenfield rewrite just wouldn't work work for something this size with the resources they had. So it stayed in business basic.

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

#24
post #20

Earlier quoted context omitted.

I'm a fan of continuous refactoring, making small improvements to code and environments constantly, rather than trying to do everything all at once. It might not be as satisfying, but it's less risky and a lot more realistic in most work environments.

The problem is when you need to change your "platform". I worked on a 300k LOC business basic application at one point. The big question everyone was asking is how do you move to something else? Everyone wanted something else, they started writing new services on top of the old system, they had some ideas on where to go, but it just didn't seem like a gradual rewrite was possible. And to be honest, a Greenfield rewri…

Isn't that the usecase for the Strangler app? https://www.martinfowler.com/bliki/StranglerApplication.html

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

#25
post #3

Kind of, but not really. When I complain about that product I almost always complain about marketing, intransigent leadership, etc. Ostensibly technical debt killed the product, but technical debt is almost always a symptom not a cause. Technical debt can get out of control, but you have to wonder how it got to be that way.

It gets that way by working in a feature factory.

https://hackernoon.com/12-signs-youre-working-in-a-feature-f...

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

#26
Yes and no.

The project wasn't killed specifically because "you have technical debt". It was killed because there was no way for anyone to be effective with the combination of poor undocumented code.

"We need to change the email message that goes out when someone registers". This took a team of (4?) people 5 calendar days to change. As a contractor, I had to vpn in to one system, then remote desktop over another vpn to another system. Building web apps, these dev systems were not allowed to talk to the internet at all, so things like pulling external dependencies (security libraries, templating libraries, etc) was impossible - pretty much everything was handrolled, largely due to this restriction.

The last big killer was that the system was not passing accessibility audits. Trying to determine where to make a change to any single element would take minutes to hours, vs seconds to minutes you'd normally expect. Much of the 'templates' used were the result of a SQL statement joining 12 tables (html_meta, html_form, html_link, html_grid, etc) and complex concat()s, so adding a page or making a change might take an hour to track down the appropriate collection of tables, then figure out a SQL script to run, then send it to the person who had permissions to make updates to the SQL, then wait and see.

Did the technical debt itself kill the project? Technically no, but the inability to do anything productive in a reasonable amount of time forced the project to shut down.

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

#27
I have seen a product getting killed by trying to resolve technical debt. The refactor took nine months and in the end didn't work better.

I am a big fan of constant refactoring on a small scale but I am very skeptical of large refactoring of a whole project. You may end up with something that's just different but not really better.

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

#28
post #24

Earlier quoted context omitted.

The problem is when you need to change your "platform". I worked on a 300k LOC business basic application at one point. The big question everyone was asking is how do you move to something else? Everyone wanted something else, they started writing new services on top of the old system, they had some ideas on where to go, but it just didn't seem like a gradual rewrite was possible. And to be honest, a Greenfield rewri…

Isn't that the usecase for the Strangler app? https://www.martinfowler.com/bliki/StranglerApplication.html

Not when in 30+ countries with different modifications made in each country
Post reply on HN