40 ms·

Agreed. Imagine you’re a CEO: Why on earth would you want your expensive engineers reworking something that already makes money? It seems much more sensible to

by jckahn 3y ago

Agreed. Imagine you’re a CEO: Why on earth would you want your expensive engineers reworking something that already makes money? It seems much more sensible to leave the working code alone and focus on new revenue-generating opportunities.

bbbobbb 3y ago
That's not what the post is about. They describe the process as mostly fixing issues with existing software, so the motivation is that something is broken or not working as required anymore. Refactoring it is just one of possible parts of the process, much opposed to 'yeah this legacy code is broken dogshit and needs to be rewritten even though the current software is already written, proven and works for 99% of the stuff we need' approach.
- JohnBooty 3y ago
  [Refactoring] is not what the post is about. Not directly, but kinda, at least in my experience. Clients and management generally understand that old code needs to be maintained. They don't love that reality, but that's not generally a tough sell unless they're completely clueless. And they're usually not completely clueless. The tension in my experience comes when an engineer wants to perform something other than the fastest, sloppiest, filthiest duct-tape maintenance imaginable. Management accepts the need for fixes, but often does not have the technical/domain knowledge to understand the short- and long-term merits of Proposed Fix A versus Proposed Fix B. And naturally, incentives heavily push management toward the quick fixes by default. Time is money, after all. And managers are expected to meet quarterly and annual OKRs. We don't have a good way to quantify the long-term value of a "proper" fix versus a "duct tape" fix. And so on. So for me maintenance work is difficult to separate from notions of longer-term software maintenance such as refactors, dependency upgrades, etc.
- robocat 3y ago
  > Refactoring I personally don't believe refactoring should ever be part of "maintenance". Maintenance needs to avoid YAGNI and avoid the engineers natural desire for over-engineering and unnecessary perfect polishing and abstruse abstraction. Refactoring is something that should be driven by new features (or worst case towards rewrite), and few have the skill to do it well. I'm not arguing the sibling strawman that maintenance be "the fastest, sloppiest, filthiest duct-tape maintenance imaginable." Excelling at maintenance is highly skillful work and often poorly rewarded.
  - dragonwriter 3y ago
    > I personally don't believe refactoring should ever be part of "maintenance". Of course it shouldn’t, because software maintenance does not exist. Programs don’t degrade with use. All “maintenance” on software is, like new development, the implementation of new context->behavior combinations, and calling it something different is a result of applying an inappropriate physical-product metaphor.
    - JohnBooty 3y ago
      Of course it shouldn’t, because software maintenance does not exist. Programs don’t degrade with use This is some real pedantic gymnastics and you're not even correct. The word "maintenance" doesn't imply some kind of physical product metaphor. Sorry. That's not what the word means.
    - SideburnsOfDoom 3y ago
      > software maintenance does not exist There are several activities in software that are similar to maintenance of physical products. e.g. * that parsing library that you used 2 years ago and was in good working order then, is now outdated and has known vulnerabilities that are not present in the latest version, apply update. * Those cloud-hosted databases that you use are an older version that the cloud vendor has deprecated and will some time withdraw support for, apply migration to a later one.
  - JohnBooty 3y ago
    Well, I certainly agree that engineers tend towards YAGNI and this must be avoided. Refactoring is something that should be driven by new features (or worst case towards rewrite), This overlooks a whole other class of factors that can drive maintenance: changes in the environment. Assuming we're talking about a program that does something useful and isn't just a screensaver, it's probably ingesting data from the outside world. That data can change in a variety of ways. API partners and users can introduce changes on their end and will eventually find new and annoying edge cases. Or maybe the volume of data increases by 100x and changes must be made on your end. Or maybe your software sort of rots as the security vulnerabilities pile up. Eventually you've got to make major version or point upgrades to the framework and/or various dependencies. We want to handle these demands judiciously and as a rule, yeah, refactoring isn't generally going to be the answer but sometimes it is.
riku_iki 3y ago
> Imagine you’re a CEO: Why on earth would you want your expensive engineers reworking something that already makes money? CEO will start looking at this topic if app performance/stability metrics will start making impact on revenue stream, aka app is slow and stop working every day and customers go away because of that.
- esafak 3y ago
  Which happens if the CEO is conscientious enough to insist on collecting and looking at those metrics.
  - pixelrevision 3y ago
    Heh. Going to be a lot less maintenance work if they are.
- JohnBooty 3y ago
  True, but app performance/stability metrics are (often extremely laggy) trailing indicators of code quality. So by the time the app starts falling over, things are extremely rotten, and it's not necessarily correlateable to any specific maintenance decision(s).
  - tangjurine 3y ago
    By the time the app starts failing, usually the people who wrote it got burned out and left :/
dagw 3y ago
It is not at all obvious that trying to develop new revenue-generating opportunities will actually bring in more revenue long term compared to optimising and improving existing revenue generating sources. And it's not like the old code stops working once you start reworking it. Give your engineers N months to rework the old code, and if it's not better you don't have to deploy it. Every larger company I've worked at had enough engineering overhead that they could afford to have small teams working on both reworking old stuff and creating new stuff, while the main teams kept the working stuff generating revenue.
juliangamble 3y ago
Security and risk. You can run several different code/pom/package.json scanner tools that will articulate a risk that will send your IT security department into a panic attack, which you can sell as time you need to spend fixing things.
whateveracct 3y ago
CEOs tend to be short-sighted when it comes to engineering management, that's true.
- chii 3y ago
  and yet the CEO would not find it ridiculous to spend money maintaining plant and equipment in the factory. It's just a lack of understanding. They imagine they understand, because software doesn't get worn out, and doesnt degrade obviously!
- deleted 3y ago
  [deleted]
fsckboy 3y ago
> focus on new revenue-generating opportunities in mature industries, there aren't new revenue generating opportunities, there is only getting better at what you ordinarily do; all marketshare growth comes at the expense of competitors.
- thfuran 3y ago
  I think that’s overstating things a bit. Even in mature industries, new technology can change the field. But it certainly isn’t all about a hyperfixation on growth.
hinkley 3y ago
Why would you turn off manufacturing equipment to do routine maintenance? It’s making you money when it’s turned on, and not when it’s turned off, after all.
- varjag 3y ago
  Did ball bearings in application's garbage collector wear out? As an embedded dev I have thousands of devices that were commissioned and are on 24/7 duty. The oldest still running fleets I believe date back to 2007. Some of them had firmware updates, but many of them (despite numerous bugfixes and improvements since) run on original software. Customers are reluctant to update if there's no specific need arises in their static operational environment. Naturally in business logic world the requirements are never as static. But when they do change you can likely sell the management on it as necessary development.
  - hinkley 3y ago
    The “seals” wear out all the damned time, which is basically the same thing.

by jckahn 3y ago

bbbobbb 3y ago

That's not what the post is about. They describe the process as mostly fixing issues with existing software, so the motivation is that something is broken or not working as required anymore. Refactoring it is just one of possible parts of the process, much opposed to 'yeah this legacy code is broken dogshit and needs to be rewritten even though the current software is already written, proven and works for 99% of the stuff we need' approach.

JohnBooty 3y ago
[Refactoring] is not what the post is about. Not directly, but kinda, at least in my experience. Clients and management generally understand that old code needs to be maintained. They don't love that reality, but that's not generally a tough sell unless they're completely clueless. And they're usually not completely clueless. The tension in my experience comes when an engineer wants to perform something other than the fastest, sloppiest, filthiest duct-tape maintenance imaginable. Management accepts the need for fixes, but often does not have the technical/domain knowledge to understand the short- and long-term merits of Proposed Fix A versus Proposed Fix B. And naturally, incentives heavily push management toward the quick fixes by default. Time is money, after all. And managers are expected to meet quarterly and annual OKRs. We don't have a good way to quantify the long-term value of a "proper" fix versus a "duct tape" fix. And so on. So for me maintenance work is difficult to separate from notions of longer-term software maintenance such as refactors, dependency upgrades, etc.
robocat 3y ago
> Refactoring I personally don't believe refactoring should ever be part of "maintenance". Maintenance needs to avoid YAGNI and avoid the engineers natural desire for over-engineering and unnecessary perfect polishing and abstruse abstraction. Refactoring is something that should be driven by new features (or worst case towards rewrite), and few have the skill to do it well. I'm not arguing the sibling strawman that maintenance be "the fastest, sloppiest, filthiest duct-tape maintenance imaginable." Excelling at maintenance is highly skillful work and often poorly rewarded.
- dragonwriter 3y ago
  > I personally don't believe refactoring should ever be part of "maintenance". Of course it shouldn’t, because software maintenance does not exist. Programs don’t degrade with use. All “maintenance” on software is, like new development, the implementation of new context->behavior combinations, and calling it something different is a result of applying an inappropriate physical-product metaphor.
  - JohnBooty 3y ago
    Of course it shouldn’t, because software maintenance does not exist. Programs don’t degrade with use This is some real pedantic gymnastics and you're not even correct. The word "maintenance" doesn't imply some kind of physical product metaphor. Sorry. That's not what the word means.
  - SideburnsOfDoom 3y ago
    > software maintenance does not exist There are several activities in software that are similar to maintenance of physical products. e.g. * that parsing library that you used 2 years ago and was in good working order then, is now outdated and has known vulnerabilities that are not present in the latest version, apply update. * Those cloud-hosted databases that you use are an older version that the cloud vendor has deprecated and will some time withdraw support for, apply migration to a later one.
- JohnBooty 3y ago
  Well, I certainly agree that engineers tend towards YAGNI and this must be avoided. Refactoring is something that should be driven by new features (or worst case towards rewrite), This overlooks a whole other class of factors that can drive maintenance: changes in the environment. Assuming we're talking about a program that does something useful and isn't just a screensaver, it's probably ingesting data from the outside world. That data can change in a variety of ways. API partners and users can introduce changes on their end and will eventually find new and annoying edge cases. Or maybe the volume of data increases by 100x and changes must be made on your end. Or maybe your software sort of rots as the security vulnerabilities pile up. Eventually you've got to make major version or point upgrades to the framework and/or various dependencies. We want to handle these demands judiciously and as a rule, yeah, refactoring isn't generally going to be the answer but sometimes it is.

riku_iki 3y ago

> Imagine you’re a CEO: Why on earth would you want your expensive engineers reworking something that already makes money? CEO will start looking at this topic if app performance/stability metrics will start making impact on revenue stream, aka app is slow and stop working every day and customers go away because of that.

esafak 3y ago
Which happens if the CEO is conscientious enough to insist on collecting and looking at those metrics.
- pixelrevision 3y ago
  Heh. Going to be a lot less maintenance work if they are.
JohnBooty 3y ago
True, but app performance/stability metrics are (often extremely laggy) trailing indicators of code quality. So by the time the app starts falling over, things are extremely rotten, and it's not necessarily correlateable to any specific maintenance decision(s).
- tangjurine 3y ago
  By the time the app starts failing, usually the people who wrote it got burned out and left :/

dagw 3y ago

It is not at all obvious that trying to develop new revenue-generating opportunities will actually bring in more revenue long term compared to optimising and improving existing revenue generating sources. And it's not like the old code stops working once you start reworking it. Give your engineers N months to rework the old code, and if it's not better you don't have to deploy it. Every larger company I've worked at had enough engineering overhead that they could afford to have small teams working on both reworking old stuff and creating new stuff, while the main teams kept the working stuff generating revenue.

juliangamble 3y ago

Security and risk. You can run several different code/pom/package.json scanner tools that will articulate a risk that will send your IT security department into a panic attack, which you can sell as time you need to spend fixing things.

whateveracct 3y ago

CEOs tend to be short-sighted when it comes to engineering management, that's true.

chii 3y ago
and yet the CEO would not find it ridiculous to spend money maintaining plant and equipment in the factory. It's just a lack of understanding. They imagine they understand, because software doesn't get worn out, and doesnt degrade obviously!
deleted 3y ago
[deleted]

fsckboy 3y ago

> focus on new revenue-generating opportunities in mature industries, there aren't new revenue generating opportunities, there is only getting better at what you ordinarily do; all marketshare growth comes at the expense of competitors.

thfuran 3y ago
I think that’s overstating things a bit. Even in mature industries, new technology can change the field. But it certainly isn’t all about a hyperfixation on growth.

hinkley 3y ago

Why would you turn off manufacturing equipment to do routine maintenance? It’s making you money when it’s turned on, and not when it’s turned off, after all.

varjag 3y ago
Did ball bearings in application's garbage collector wear out? As an embedded dev I have thousands of devices that were commissioned and are on 24/7 duty. The oldest still running fleets I believe date back to 2007. Some of them had firmware updates, but many of them (despite numerous bugfixes and improvements since) run on original software. Customers are reluctant to update if there's no specific need arises in their static operational environment. Naturally in business logic world the requirements are never as static. But when they do change you can likely sell the management on it as necessary development.
- hinkley 3y ago
  The “seals” wear out all the damned time, which is basically the same thing.