Hacker News Reader

Comment by lamontcg | Hacker News Reader

I've been in-house and wound up being the last programmer maintaining the massive pile of tech debt. We had ordering issues and couldn't run our tests in parallel due to global state problems. And it wasn't a mistake here or there, it was the accumulation of a decade of issues. I took a few stabs at it, but doing a week or two of work here and there never moved it significantly forwards. The minitest author took a run at fixing a few of the problems and recommended scrapping the tests entirely and doing a full rewrite. There was no way that I had the time to do that (literally, like me). The answer of course was that the company was effectively dead and it was long past time to quit.

View on HN

> And it wasn't a mistake here or there, it was the accumulation of a decade of issues.

Nodding my head to this. I feel like this is why it’s so hard to convince certain coworkers to take a hard line on code quality. “The class is already 2000 lines of code long, adding one more method isn’t the end of the world.”

No one sets out to turn a 100-LoC class into a God class in one PR. It’s always a “death of a thousand cuts” situation. That’s why we need rules which strike some people as arbitrary or draconian, but which I see as a useful tool to fight backsliding, like these [1]. You have to draw the line somewhere.

1. https://thoughtbot.com/blog/sandi-metz-rules-for-developers

Yes, but what do you do once you have a mess and you're understaffed, and the horse left the barn a long time ago?

You clean it up. I've cleaned up projects that we're total shit shows and the cleanup paid dividends when the time came to update or change that part of the code.

Even if a project has gone to seed, things rapidly get better when you start to do things the right way again.

Yes, I started to clean it up. If I had stayed there for another 10 years, I might have finished.

That’s when engineering management needs to make some tough choices, like “No new features on the roadmap until we get our house in order and pay down the tech debt”. Give the staff who are there the time they need to plug the holes in the ship.

And if engineering management doesn’t have a seat at the table, i.e. if product or sales or the C-suite looks at engineering as a bunch of order-takers, maybe that company isn’t meant to be long for this world and it’s time to start polishing our CVs.

I’m an engineer, not a miracle-worker. My help isn’t for people who need it, it’s for people who want it.

> That’s when engineering management needs to make some tough choices, like “No new features on the roadmap until we get our house in order and pay down the tech debt”.

If I had a penny for each time I'd seen this argument made and knocked back...

> If I had a penny for each time I’d seen this argument made and knocked back…

That’s what paragraphs 2 and 3 of my comment are for.

And those really don't change anything about my response. Your solution seems to be "if you're at a bad company, quit", and like I said earlier: "Working only with Good code is a luxury decision".

Software engineering is still a seller's market, even with the recent rash of firings. Most engineers are much more employable than they give themselves credit for.

Saying "Working only with Good code is a luxury decision" is like saying "I can't afford to buy fruits and vegetables, so I'm going to live off of instant ramen for the rest of my life." Like, yes there are people who actually live like that. But it's an incredibly short-sighted way to live, and they'd be better-served by making (drastic) lifestyle changes.

Mandating good code is an investment that costs more in the short term, but provides dividends in the form of faster feature delivery over the long-term.[1] It's a luxury for apps that don't expect to have a "long-term", just like fruits and vegetables are a luxury for people who don't expect to live past 50. But it's a necessity for developers who want their apps to be extensible and responsive to change.

EDIT: looks like we reached the limit on the comment reply chain. I’d agree with your comment below, and I’m not here to defend the naming choice of the method in question. The reason I love the Ruby community is, among other things, because of the whole MINASWAN ethos. And I think the same goal behind the method name could have been accomplished in other ways. I’m here to dispute the idea of code quality as a luxury, that’s all. Sounds like we’ll have to agree to disagree on that point.

1. https://miro.medium.com/max/605/1*RcmxmnYCcKTrCdJpCo7WYg.png

> Mandating good code is an investment that costs more in the short term,

Yes, the system we work in demands short term growth and profits. This is why there is a problem, not because developers "suck".

Reply on news.ycombinator.com