Live data from Hacker News

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

news.ycombinator.com

71–80 of 331 posts

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

#71

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…

This. It's not like there is a sign saying "Technical Debt Required to Proceed"...but rather the slow death from a thousand cuts to productivity caused by having to analyze every potential system, process, template, stored procedure, etc, etc...to make any stable(ish) change. Even if things are loosely coupled and not dependent on each other...you still have to go in and make those changes. Telling this to a room full of non-understanding management is a whole different challenge...

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

#72
post #44

Earlier quoted context omitted.

For the second one, you must have been receiving a lot of traffic for template rendering to be such a bottleneck. Why not upgrade the server?

They upgraded the server of course, to as much as they could afford. But it wasn't enough, the rendering load soon caught up. First of all because their number of visitors grew, but also because they wanted to add new features to their JSF pages and every new feature required extra rendering power as well.

Could you not scale this horizontally? We do all template rendering server side, though it is JSP and not JSF.

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

#73
post #33

Knight Capital lost $465 million in 45 minutes caused (at least in part) by technical debt and poor development practices. Summary: http://pythonsweetness.tumblr.com/post/64740079543/how-to-lo...

It is surprising there wasn't a circuit breaker here.

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

#74
post #52

The last place I worked at will die because it will take them years to migrate from Oracle to postgres due to "technical debt" (the codebase is coupled with the database to a hilarious degree; business logic in triggers, huge plsql packages, plain sql queries in the java codebase, halfassed homerolled ORM). They're not getting as many new customers as they could because, for various reasons, the Oracle licensing term…

Hey, sounds like we worked at the same place! That, or the "wedded to Oracle for life" is a common antipattern. I'd add "shared everything architecture" to the horrors.

Yeah, once you get that deeply entrenched in Oracle, it's almost impossible to get away, and after that experience I vowed never to work at another Oracle shop.

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

#75
I've seen a whole company killed by technical debt. Because the software was written so badly far more developers had to be hired to firefight than the company could afford. The technical support team was similarly bloated to deal with the endless problems the customers had. Sales were low due to the bad reputation.

A rewrite was started, but never got anywhere. The company folded under the weight of its massive salary costs.

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

#76
post #72

Earlier quoted context omitted.

They upgraded the server of course, to as much as they could afford. But it wasn't enough, the rendering load soon caught up. First of all because their number of visitors grew, but also because they wanted to add new features to their JSF pages and every new feature required extra rendering power as well.

Could you not scale this horizontally? We do all template rendering server side, though it is JSP and not JSF.

That was considered but it would of course take some refactoring on the back end, and it would still cost quite much in hardware. The thing with JSP and JSF is, they do ok as long as your content is relatively static, because then rendered content can be cached. In case of this company, their most visited page was the list with search results which by its very nature was not very static at all.

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

#77
post #66

The closest I've come was a Rails project I inherited from a star developer who had just left the company. It was a B2B project that involved importing large Excel spreadsheets of various different formats into a standardized database for itemized review. The code was pretty sloppy, but didn't deviate much from standard Rails idioms. Not many people on the team understood Rails well enough to read it, but I did. Bug…

I don't think I ever seen an Excel / CSV import implementation that wasn't a huge mess.

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

#78

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…

This account kind of comfort me in what I think of technical debt : most of time, the problem is most likely lack of documentation than anything else.

I don't see how a big project could be coded without containing anything specific to the project. And even then, the architecture by itself is unique and deserves documentation.

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

#80

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…

This sounds less like technical debt, and more like liabilities of over engineering. Possibly feature creep.

That is, technical debt is not necessarily tangled over-engineered code. It is more compromises that were made to actually ship and operate in the world. You can see this in the world with devices.

Consider, technical debt is the reason you have AC delivered to your house going through as many converters as you do devices. Often to the same target power characteristics for those devices. It is not the reason that your coffee machine that also grinds and whatever, is likely to fail within the year.

Another example; Technical debt is the reason we are still predominantly using petrol for automobiles. It is not the reason the dashboards are horribly non-responsive on modern cars.

Post reply on HN