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-...
Ask HN: Have you ever worked on a product that was killed by technical debt?
21–30 of 331 posts
Re: Ask HN: Have you ever worked on a product that was killed by technical debt?
#22I'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.
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?
#23I'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.
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?
#24Earlier 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…
Re: Ask HN: Have you ever worked on a product that was killed by technical debt?
#25Kind 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.
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?
#26The 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?
#27I 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?
#28Earlier 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