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

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

#121

Post by lostcolony » Tue, Jan 17, 2017, 4:00 PM UTC

maxxxxx wrote: post #56

lostcolony wrote: post #42

Earlier quoted context omitted.

I've had the opposite happen every time the team I've been on decided to refactor a large portion (or even the entire code base). Every time, what was a source of constant bugs (i.e., X bugs per week, every week, never lessening), became tractable and moved to stable post the rewrite (X bugs first week, .7x bugs second week, etc, until finally we're encountering the odd bug only once every few months, if at all). I'm…

I was talking about enterprise projects that had had years of development, always changing personnel and had to follow complex and changing business rules. These tend to be ugly and difficult to work with after a few years of development. In my view the only way to deal with these is to break them down into smaller components and then refactor. But that turns then into a political issue because the managers (and a lo…

Yeah, I could see that. I've been in those environments too; I have no data points from that, because getting the okay to refactor was so hard it never happened while I was on the team (I'd been on projects that claimed to have refactored the code, but then it was mixed as to whether people claimed it was a success or a waste).

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

#122

Post by vkuruthers » Tue, Jan 17, 2017, 4:00 PM UTC

masukomi wrote: post #108

lhnz wrote: post #15

Yes. Technical debt rendered it difficult to create features, and difficult to hire. The project dragged on as engineers came, tried to refactor and then left. I didn't stay. My understanding is that it was never released, so all of the money the company put into the project was wasted. This is maybe different from what people normally consider 'technical debt'. I don't mean just code aesthetics but also bugs, redund…

We have lots of tech debt (we are gradually paying it down), but we keep engineers for a loooong time (they basically don't leave unless they move) because of the social aspects of our team. A bunch of really nice, helpful people, who really want to make things better but are willing to balance "good" with "practical".

That sounds like a good setup. Is there anything in particular the management does to keep engineers around?

Similar situation at my place (great co-workers, good product space), but poor management, leading to lots of turnover.

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

#123

Post by Bahamut » Tue, Jan 17, 2017, 4:01 PM UTC

Bartweiss wrote: post #95

Bahamut wrote: post #70

Earlier quoted context omitted.

Isn't this precisely technical debt? Unless you want to split hairs and call this a technical massacre...

It is, but the question is what "killed" by technical debt means. It's uncommon but not unheard of for code to reach the point of "we can't do that". Mostly, though, the proximate cause of death is a funding shortage or management decision to shutdown. Technical debt is just driving the cost overruns or inefficiencies that kill the project.

I don't disagree that the root cause in that situation is not engineering in most situations and that it usually is an indication of a symptom, but attempting to change the meaning of the term itself is not a great approach for communicating that.

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

#124

Post by Bartweiss » Tue, Jan 17, 2017, 4:02 PM UTC

ryandrake wrote: post #107

Bartweiss wrote: post #93

Earlier quoted context omitted.

This is a great example of how technical debt 'kills'. It's not a murder, it's negligence and a slow demise. I went through one of these projects. The tech debt was never as bad as you describe, but it was a small company operating on a short runway. It also taught me an unfortunate lesson about non-technical founders and the dangers of outsourced code. The MVP for the company had been bought off the shelf. It worked…

Seen this a lot. A lot of companies think they are "product" companies, but due to their unwillingness to push back on customers, they become custom engineering shops, bolting on little one-off mods to their project over and over to appease bad customers (or to appease POTENTIAL customers who haven't even bought the product yet). Stop me when you recognize this one: "Hey your product is great, but we really want some…

Ouch, that's almost word-for-word from the company that died of debt.

It was enterprise sales, so customization was unavoidable, but no one was differentiating between big and small changes, or big and small buyers. The product was desperately struggling to do ~3 things at once, and still being sold to potential buyers on the promise of a fourth thing it would do "soon".

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

#125

Post by luca_ing » Tue, Jan 17, 2017, 4:04 PM UTC

vkuruthers wrote: post #114

luca_ing wrote: post #81

I'm currently working on the reincarnation of a project that was killed by technical debt -- TWICE. The original codebase was about 20 years old. It was control code for something best described as an industrial robot. Written for the last 20 years by greybeards who knew a lot about the manufacturing process, and were reasonably good at getting a product out the door. But the whole thing was riddled with #ifdefs for…

Sounds like the software managers were not on top of things, otherwise how would they have allowed this type of design to be implemented? Not to say I haven't seen this effect myself many times...

Management, you say?

Management ordered the creation of new software. Shouldn't that be enough?

The project lead was responsible for this design, and above him there was nobody with any expertise in the matter.

From what I've heard he's an extremely good C++ programmer. He's just a terrible architect.

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

#126

Post by pjc50 » Tue, Jan 17, 2017, 4:07 PM UTC

msluyter wrote: post #74

Lewton wrote: 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.

Oracle is a form of technical and financial debt all its own.

I wasn't directly involved in but had a good view of our university's finance modernisation woes: http://news.bbc.co.uk/1/hi/education/1634558.stm https://www.admin.cam.ac.uk/reporter/2001-02/weekly/5861/1.h... - although in fairness the inflexibility and disorganisation were existing features of the institution, and Oracle merely exacerbated them.

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

#127

Post by mattmanser » Tue, Jan 17, 2017, 4:07 PM UTC

taeric wrote: post #80

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…

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 yo…

Saying that technical debt is only deliberate is an old argument[1], but usage defines meaning and modern usage is that "technical debt" is a catch-all term. It just means bad code we know should be fixed.

[1] 2009 - https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

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

#128

Post by beat » Tue, Jan 17, 2017, 4:08 PM UTC

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…

I should add here that the "antiquation" case is the one that has caused the most observed grief in my career. The forces causing failure are coming from outside the code/business (dependence on an outside vendor), and sometimes collide with forward momentum of other parts of the code (i.e. that graph library will never, ever work with Java 7, to name an example). These become life-or-death situations, and the tendrils of the product dependency are often deeply integrated. It might be easier to rewrite than to fix.

Also, this case can impact not just products, but organizations. You can still find teams dependent on an antique commercial version control system or IDE that greatly slows down or even stops work. I've tech-led jumps to new version control systems a few times, and it's always riddled with anxiety, strain, and management angst. (And it always makes the team far happier and more productive!)

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

#129

Post by byroot » Tue, Jan 17, 2017, 4:08 PM UTC

samwilliams wrote: post #90

byroot wrote: post #77

Earlier quoted context omitted.

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

Do you mean Excel to CSV? Or a CSV importer? I totally agree about Excel importing, but CSV is trivial, no? Here is an Erlang version I happened to write yesterday: lists:map( fun(Row) -> string:tokens(Row, [SepChar]) end, string:tokens(InputStr, "\n") ). EDIT: I know this version won't support escaped separator/newline characters, but I made it for a specific use case in which I knew that would not occur. Adding tha…

I'm not talking about parsing. It's a mess in it's own right of course (encoding, line terminators, etc as others mentioned).

I'm talking about the actual conversion from tabular data to relational. Most of the applications I've worked on had this in one form or another.

So you end up with users downloading an export of their data in CSV, editing it in Excel in various ways, and then reimporting it in the application.

Every company I worked for, this kind of feature was always in the top 3 in term of support load.

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

#130

Post by objnoteqnull » Tue, Jan 17, 2017, 4:12 PM UTC

Worked on a product that was written in a legacy technology and built over two decades. Company does not want to invest further in the product and just want to support existing clients that had done lot of customization on top of existing codebase. New players have come into the market and eaten away the market share of the category the product competes in. Its a slow death for the product now. Management feels that it is better to buy a new product built by another company rather than building the same product in-house with no guarantee of returns.