5 ms·

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 oc

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.

vkk8 5y ago
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 5y ago
  I’m sure that some teams are like that but it is not universal
adambyrtek 5y ago
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.
- Clubber 5y ago
  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 5y ago
    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.
- mlac 5y ago
  Or throw it on the backlog to track it…
- lasereyes136 5y ago
  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 5y ago
    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 5y ago
      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.
- 5y ago
jackling 5y ago
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.
watwut 5y ago
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.
pinephoneguy 5y ago
throwawayninja 5y ago
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 5y ago
  What do you mean by the 2nd time? Did you rewrite the whole thing again some amount of time later?
foobarian 5y ago
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.
- kaba0 5y ago
  Testing is a thing.
  - xadhominemx 5y ago
    Ok, but now your “time boxed” half day refactor is two man weeks of testing, bug fixes, back and forth, etc
    - dr-detroit 5y ago
    - D-Coder 5y ago
      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.
- Silhouette 5y ago
  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.
kodah 5y ago
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 5y ago
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 5y ago

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 5y ago
I’m sure that some teams are like that but it is not universal

adambyrtek 5y ago

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.

Clubber 5y ago
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 5y ago
  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.
mlac 5y ago
Or throw it on the backlog to track it…
lasereyes136 5y ago
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 5y ago
  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 5y ago
    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.
5y ago

jackling 5y ago

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.

watwut 5y ago

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.

pinephoneguy 5y ago

throwawayninja 5y ago

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 5y ago
What do you mean by the 2nd time? Did you rewrite the whole thing again some amount of time later?

foobarian 5y ago

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.

kaba0 5y ago
Testing is a thing.
- xadhominemx 5y ago
  Ok, but now your “time boxed” half day refactor is two man weeks of testing, bug fixes, back and forth, etc
  - dr-detroit 5y ago
  - D-Coder 5y ago
    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.
Silhouette 5y ago
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.

kodah 5y ago

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 5y ago

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.