[ihateolives]

In a lot of companies, feature development trumps optimizing, refactoring or removal of legacy code.

Dev: Hey Steve, I'm working on issue #4546, but it just occured to me that that if I could just refactor that one method in SuperFactory it'd make code much cleaner and easier to reuse. Just a quick fix!

Manager: No. Work on #4546.

Dev: Sure, #4546 will be done soon, but it'd be really easy fix, it just occurred to me yesterday that there's a better way to build things with SuperFactory.

Manager: No! We already closed that issue!

Dev: No problems. But I thought that now that I have some extra time until...

Manager: Look, Dave, it's working as intended, the solution was reviewed and accepted. I will not create another task. You'll take #7839 next!

[...]

Manager: Hey, Dave, I recall you had some ideas about SuperFactory. It's been acting up lately, they keep creating tickets.

Dev: Nope. None. All gone now.

Manager: But you had, right?

Dev: Yes, but I'd have to start digging in again and I don't have time for that.

Manager: Oh, ok, you're right.

[adambyrtek]

I know this is just an anecdote, but a good developer wouldn't ask the manager to approve every small refactoring or expect them to understand the importance of "one method in SuperFactory". They would have instead made a judgement call and taken the responsibility of doing the quick fix.

[commandlinefan]

> wouldn't ask the manager to approve every small refactoring

It becomes an issue if it takes more than a day. Scrum, Kanban, RUP, XP, waterfall - whatever "methodology" they say they're following, it boils down to "tell me how long this is going to take and I'll check to see how close what you said was to the time it took". If you can make a change in an hour, sure. If it takes a day, it's going to break your "commitment".

[projektfu]

Except in XP the developer will refactor before and after implementing the feature, the customer doesn’t get to say how things get done, and there is no “manager” role.

Not to say that people don’t operate completely differently and call it XP. That’s always a problem. But it isn’t “No True Scotsman”, it’s literally just not following the recipe and expecting the cake at the end.

[Silhouette]

Or... Management could choose not run their software development organisation with the kind of micromanagement strategy that requires everything to be allocated in units of one day or less. It's another red flag that has become disturbingly common in the industry and suggests managers more interested in "visibility" and "metrics" than actually doing a good job, sustainably, by trusting their technical people to do theirs.

[icedchai]

I love how "story points" aren't supposed to represent days, yet conveniently everyone winds up with 10-ish over their 2 week sprint, and it is totally micromanaged. Meanwhile none of the non-technical "product people" are ever asked to account for their time like this.

[commandlinefan]

> Management could choose not

Sure, they could, but they never have.

[selfhoster11]

No, that would be preposterous.

[lasereyes136]

While I agree with you, some managers micromanage and freak out for any change that isn't directly related to doing or fixing X. They will reject the change and it becomes painful to keep working like that because they hold it against you. Toxic workplaces exist.

[RhodesianHunter]

And in a market where developer skills are in incredibly high demand and a new job can be lined up in a couple of weeks, such workplaces should cease to exist due to lack of developers.

[bitwize]

To the average hackernews, lucrative tech jobs may grow on trees, but that is not the case for everyone, even those with technical skill. It usually takes me between three and six months to get a new job.

[Clubber]

Yes, the general rule for me is if I see something completely whack on the ticket I'm working on, I'll clean it up as long as I know there won't be collateral damage. The problem comes when these systems become so complex and so old and the people working on them don't really know what changes will affect other systems down the chain.

[bradknowles]

In Enterprise software, everything is a Chesterton's Fence.

Or a Chekov's Gun.

The problem is that you can almost never tell which is which. And sometimes they're both.

[geodel]

IME in SAFE® Agile™ world developers are fully empowered to not take decision on things which are domain of enterprise architects/ Product manager or leadership calls.

[alexeiz]

There are companies in which the process is organized in such a way that taking responsibility and doing a quick fix can put your career at risk.

[mlac]

Or throw it on the backlog to track it…

[andrewl]

You could be a good developer with a manager who gets angry if it’s discovered you took that kind of initiative.

[foobarian]

But the reason this happens is because of previous painful experiences like the following:

Dev: Hey Steve, I'm working on issue #2312, but it just occurred to me that that if I could just refactor that one method in SuperFactory it'd make code much cleaner and easier to reuse. Just a quick fix!

Manager: Huh. How much more work is it? If you can time-box it to half a day then go ahead.

Dev: Great, it should take just a couple of hours!

The change is merged and deployed, and several weeks go by...

Data Science: Hi team, we are wondering if you know if anything changed in this module in the past couple of weeks. The numbers from non-English speaking domains tanked.

Manager: Uh oh

Dev: Uh oh

Data Science: We just look at data in aggregate with significance only reached with weeks of collection. But at this point it looks like we lost millions of dollars.

Manager: oh shit

Dev: faints

... followed by weeks of post-mortems, meetings, process improvements, if not outright terminations.

[Silhouette]

Allowing technical debt to accumulate like that will, with near 100% certainty, damage your development activity sooner or later. The only exception is if you've already damaged it critically in some other way.

Some contrived example where you might lose significant money because you made a generally good change but it had a bug and that bug was somehow missed by your entire review and testing process and the consequence of that bug was able to go unnoticed for a long time in production and then the result was disastrous isn't really a very compelling counter-argument.

If you subsequently hold weeks of post-mortems, meetings, process improvements and outright terminations, the person who made the otherwise useful change that had a bug should be among the last to get called out, somewhere after the entire management chain who utterly failed to competently organise critical development and operations activities, everyone responsible for QA who couldn't spot such a critical problem early, and everyone involved in the data science who ran such a hazardous experiment without taking better precautions around validity.

[foobarian]

Well. It's not a counter-argument to anything, it's an illustration of how we end up with bad codebases, and why specifically in big enterprises. The incentives are set up exactly in the way that lead to it, particularly by making it expensive to clean up tech debt.

[Silhouette]

Fair enough if that was the point you wanted to make, though in that case I'd argue that the kind of disaster scenario you described isn't specific to big enterprises but to disastrously bad software development organisations. A lot of small organisations think they're operating at enterprise scale and make the same kinds of mistakes!

[Chris2048]

That has nothing to do with giving devs lee-way.

If you work without tests/QA, you are shooting from the hip. The scenario above as-such should not happen. If it ties in with million-dollar processes, even more so. What you are saying is "We don't trust our process, so we do as little as possible outside authorised tasks"; Instead, you should fix the process. If this led to post-mortems and process improvements, as in QA/dev process, not simply bug-fixes, then why is the process not improving and/or better trusted now?

Also, the original task is described as a "refactor", so the numbers should not be affected - was was it not just a refactor?

[foobarian]

> If this led to post-mortems and process improvements, as in QA/dev process, not simply bug-fixes, then why is the process not improving and/or better trusted now?

IME things do improve after taking those steps. But with large code bases there are a lot of layers of products over time and it's difficult (and expensive) to make sure everything is covered. And it's also a moving target.

> Also, the original task is described as a "refactor", so the numbers should not be affected - was was it not just a refactor?

IME the most useful tech debt interventions are where some legacy module is deleted or some unused code retired. Unfortunately those are often not provably without side effects and sometimes even with a diligent investigation side effects can be missed, especially when the components involved are old and original creators and product managers have left the company.

At the end of the day cleaning up tech debt has non-zero risk, guaranteed cost, and very often, in the eyes of management, negligible reward. So on average it grows and thus enterprise codebases are born.

[kaba0]

Testing is a thing.

[xadhominemx]

Ok, but now your “time boxed” half day refactor is two man weeks of testing, bug fixes, back and forth, etc

[D-Coder]

If you planned your refactor AND testing and bugfixes to take half a day, and it is going to go way over, you (a) tell your boss your estimate was off and the refactoring needs to be a separate task, and (b) revert it.

[kazinator]

Technical Manager: Dev, it's only a quick fix because there are no test cases for that area, and you're not adding any before refactoring, so then you don't think you're breaking anything.

[throwawayninja]

Left a job in 2020 over exactly that. Our customers loved when we could fix/build features in a week, but after 18 months the bloat made it impossible to ship a new feature in the same month. I actually went behind my manager's back and did a full re-write (~25k sloc down to ~15k) at the 8 month mark, but the 2nd time he put his foot down and said absolutely not. I left within a 6 months of that discussion.

[pgwhalen]

What do you mean by the 2nd time? Did you rewrite the whole thing again some amount of time later?

[jackling]

For me the issue is rarely refactoring a single method, but trying to improve features given new tools and use cases. I'm always met with the same issue that it may cause regression and we would need to allocate more QA time. Really hampers improving old code.

[kodah]

Managers should never drive technical decision making. This is one of the key offenses some companies continue to commit; they let managers think that they're still engineers. A manager, imo, needs to be paired with an engineer that has the same scope and adjacent level as the manager so that things like this don't happen.

[goto11]

Dev: If we just rewrite everything in Ruby on Rails and Coffeescript, our productivity will go through the roof after a short time investment.

Manager: Sounds great, let me know when you are finished.

[vkk8]

Is this how software development in corporations really works? I'm not a software developer, but I've contributed to some large open source projects and I thought it would be similar. Maybe with the difference that the issues would be raised by a Q/A team or other people in the company instead of random people across the internet.

[Tagbert]

I’m sure that some teams are like that but it is not universal

[watwut]

I think that issue here is that manager is approving method refactoring in SuperFactory. And I mean, I work on dysfunctional enterprise company software. My point here is that this is not how things get bad, because this is not how things work, at least where I have seen.