Hacker News Reader

Comment by teeray | Hacker News Reader

There’s a lot of orgs out there that will do all of:

1. Never consider a rewrite / v2.

2. Never schedule refactoring work.

3. Not accept any refactoring work as part of feature work, because the refactoring is always deemed more risky (despite tests). “Let’s split this PR into feature and refactor.”

So my question to these orgs is: when are we supposed to clean up the hacks to ship yesterday’s features?

View on HN

You know the answer: never. It works, doesn't it?

And they're right more often than I like.

Edit: I'm definitely not saying they're always right, or even often. I'm usually with the line of thinking of the people commenting to me. It's just, I've also seen systems that had ten years of further life and never needed their hacks fixed. We developers are sometimes too fixed on the quality.

Paying people 100’s of thousands of dollars a year to get tens of thousands’ worth of work done because everything takes eight times as long as it reasonably should is both expensive and gets old real quick.

But there is no proof it takes 8x as long or costs 100000s or more because of that; if you can prove that then many companies will say, yup, that’s a shoe in, let’s rewrite! I have been in a lot of rewrites and more often than not, it did make the tech folks happy, but it did nothing, immediately or middle/long term, to the bottom line or the productivity. Worse; the productivity plummets at first because a lot of new things have to be learned.

There is no proof that cargo cult agile improves efficiency or reduces costs but many companies do it regardless.

Your managers should be former or current software engineers who can evaluate the technical merits of a rewrite.

> There is no proof that cargo cult agile improves efficiency or reduces costs but many companies do it regardless.

But the story feels like it should work. It feels logical.

I don’t like how well you described my job

I don’t like it much either. I have friends who don’t think about such things. They tend to be happier 95% of the time. Not as useful when everything catches on fire though.

they're right over and over, until they're not and then the company tanks because they need a rewrite.

But they don't care - instead, they just start a new one and repeat the process all over again.

The mistake here - made not just by the devs complaining about tech debt, but also by all of the company's customers - is that the goal is to produce something of value. It's not. It's to produce something promising to be of value at some point in the future, getting as many people as possible, as fast as possible, to buy into that promise (and stringing the paying users, if any, along for as long as possible), and then jettisoning the whole thing once it's past its peak, escaping with riches, to do it all again, or finally go FIRE.

Yep exactly my experience working in a startup. When it was time to make a real product our of the shit spaghetti code they wrote to win customers with """working""" demos, it was too late. Bankruptcy followed.

Isn’t this a slightly different problem? The product built was just vapourware and not really doing the job. So customers went elsewhere when the real version didn’t appear in time? Often companies will win the customers with a genuine working product but complicated code and then hire like crazy and all the new developers struggle and want to rewrite it all. But they mustn’t because it is a working product earning money. So gradual improvement and controlled rewrites of sub areas that need to change the most are focused on to succeed. If a company has gone bankrupt because of spaghetti code of a demo product, it feels to me like the problem was the product being just a demo rather than it being spaghetti code?

You're not wrong! But IMO, the product was being limited to being only a "demo" product because the code was too bad to run extensively in production. I guess it was both problems.

Reply on news.ycombinator.com