Hacker News Reader

Comment by preommr | Hacker News Reader

Because long-term maintenance isn't the concern.

Most devs switch jobs in 2-5 years (or at least that's the common advice given). So the incentive is to play musical chairs, and hope that you've moved on by the time the music stops.

Software has also been such a new field that it was the startup that moved fast and broke things that got the prize rather than the slow but stable company. I think this is changing (lower barrier to entry and ever-increasing complexity). But the momentum still exists.

View on HN

Further, management notices and rewards the developer who is chewing through tickets, especially when those tickets are visible, user-facing features. If those developers are sloppy (and they tend to be), the bugs, readability issues, etc don’t get traced back to them and the rest of the team gets no glory for cleaning up after them and actually productionizing the prototype-grade shit they deploy to production.

This happened to me in one of my first jobs.

I chewed through tickets and regularly had an above average point score every sprint, even as a brand new junior developer. I sometimes had the highest on a team where everyone else had 5+ years of experience, which should have raised red flags. Heaps of praise though.

And I was doing it by taking the most direct path to it working without really knowing the potential consequences (which I didn't understand at the time).

The guy who wanted to do refactoring didn't get his contract renewed as that was not productive work.

Kudos to you for recognizing that. I know “senior” developers that wouldn’t see this effect from them or their team even if you told them.

I know because I did, multiple times. It’s futile. Your best move is to leave in that situation.

I think the heart of this isn't devs changing jobs. It's execs. I know plenty of devs who will be "irrational" about quality in that they build for sustainabilty and longevity far beyond their personal economic incentives.

But when those same devs go up the chain to improve practices or clean up tech debt, they rarely end up happy. I think that's because executive turnover is also fast and the rewards for underinvestment are much larger. Executive compensation is often tied to stock price and other short-term metrics, and executive tenure is also quite short. That gives them a strong incentive to cut anything that pays off over the long term.

Which I think ties back to his professionals vs amateurs thing. One thing that distinguishes professionals is standards. Doctors won't prescribe you anything you want. Real engineers will refuse to build things that will collapse. But a lot of devs are more minions than professionals; if the boss says to build X, they'll build X. Whether that's good for the company, the customers, or society isn't relevant.

I've rarely seen progress get made when it's framed as "I want to clean up tech debt." To execs it seems like moving deckchairs rather than moving the number (which to be fair, it sometimes is).

"In order to release feature x which customer y cares about, we need to clear up tech debt / refactor z" is a much better way of getting execs on board.

Excellent point, it needs to offer a concrete benefit. Simply saying “it will make it easier to write new features going forward” won’t convince anyone.

For sure. That's definitely where many organizations are. "To cook breakfast this morning, I propose we clean up last night's dinner mess. Here is my 27-slide deck."

But I think it's also worth orgs getting to the point of defaulting to just cleaning up after dinner, and also cleaning as they cook. Having to have a specific, urgent reason to clean up a mess is a fine argument for 13-year-olds to make as they come to understand how a household works. But it's tiresome when nominal adults refuse to accept that the future eventually arrives.

Being irrational about quality does not lead to easier to maintain software. You need to be rational about it and the distinction matters a lot.

You can go all petty on minor idioms and force everyone to use all the sonar rules and all it will create is a lot of busywork with zero improvement on maintainability. And I have seen this dynamic to happen more then once.

That's not the kind of irrational I'm talking about, which is why I put the word in quotes and then explained exactly what I meant in the same sentence.

Also there can be other real life business constraints. Sometimes the project need more devs but there aren't any to add. Sometimes the deadline is truly set in stone and if you miss it you are truly fucked. In times like these you have to cut corners and these are the easiest corners to cut for short term speed.

"Amaterur vs professional" feels "Good vs Bad" for me but real life is never as simple as that.

Software today is a complicated mess. On the consumer side, peoples minds are so fickle and they want the latest shiny object or app; on the software side, companies are constantly inventing new ways to do the same old thing; hardware is getting tossed in the dump, when it is actually still very viable.

It's fascinating to see what people are doing with old hardware like Commodore 64, because it's understandable and doesn't change at this point. If we can use hardware that is almost 50 years old, why are cycling through things so rapidly?

The fun starts when you later get blamed for cutting those corners in response to that true business requirement.

That's the advice I've given: No equity? Chose the tech stack of the next place you want to work at and leave after 2 years.

OTOH, business itself cannot spare any manpower to maintain old code.

Not their fault either, because maintaining old code is hard, frequently will introduce new bugs, and potentially halt business. Less hope for migrating into newer engine / language.

It's simply that software development is hard and we lack standardization more than any other industries.

Reply on news.ycombinator.com