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