> 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.
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...
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.
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.
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