6 ms·

> Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. While th

> Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line: When modifying existing code, do a very careful cost-benefit analysis; On the one side is the cost of a rebuild. On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future. I realise that this is essentially an impossible requirement. We cannot forsee the future. But: We can make predictions. And when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Because, dragging a legacy-system along incurs it's own set of costs. This is especially true when it's not just maintained, but modified and extended. And many of those costs have a nasty tendency to remain hidden until they suddenly don't, and at that point, people often already expended inordinate amounts of resources on them. So yeah, the first instinct should be: Use what already exists. But check the costs of doing so. Premature rebuilds are a waste of resources. And so is holding on to legacy systems past their expiration date.

PartiallyTyped 3y ago
Personal example I am living through. By the estimates of another team, it will take 2-3 months to build a wrapper around their codebase (it is that entangled) and throw that in EC2. The whole project will become infested with that codebase and those issues because as we all know, a “temporary fix” is never temporary. The codebase doesn’t cover anywhere near what we have in mind for features and extensibility is … yeah.
elygre 3y ago
I notice that on your “one side”, you have the cost of the rebuild — but not the “projected cost of keeping this thing and maintaining it”. That’s a common fallacy of programming: the existing code is convoluted and hard ti maintain, but the new code I would replace it with will be much better and much cheaper to maintain.
- usrbinbash 3y ago
  That's a very good point you make there, and I should have mentioned that in my post. Yes, the cost of the rebuild itself, PLUS it's own maintenance, fit with the rest of the codebase, extensibility and so on, must be considered in that equation. I glanced over that, because usually the rationale for a good rebuild is an improvement regarding exactly these metrics.
- djbusby 3y ago
  Yea, they(we) always say the new code will be better. Yet, eventually the new code becomes the old code and the cycle repeats. Assumptions and Environment change. New becomes old. And old has maintenance cost.
- XorNot 3y ago
  Conversely...in a lot of cases you can reasonably project it's likely you won't be maintaining it. So what you're really projecting is how much trouble you expect to save yourself for your forseeable remaining time at the company.
- kmoser 3y ago
  In addition to projected cost to maintain, there is also the potential ill will you are continuing to generate with your customers if the existing buggy/legacy system affects them. Your reputation with your customers matters. This is one of the biggest factors I see companies ignore all the time.
m3kw9 3y ago
Reusing code cause issues if you are not very careful because if not checked people often keep adding to it or someone modified it for their use case and breaks others. Many times is just better not to reuse
- edgyquant 3y ago
  This is what tests are for
dfcowell 3y ago
This is a really good addition, and something I wish I’d thought to cover. I’ve added a link back to this HN thread to the post so that people who find it from other sources can benefit from your perspective!
goto11 3y ago
> when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Only developers who love greenfield or need a new framework on the CV would suggest a company could lose money by not rebuilding. If the developers are not competent enough to write maintainable code or maintain existing code, then you will have exactly the same difficulties after the rebuild. If they are competent enough to write maintainable code and maintain existing code, then you have no need for a rebuild. Just adapt and extend the existing code to meet the new requirements.
- usrbinbash 3y ago
  > If the developers are not competent enough to write maintainable code or maintain existing code Or if the old system simply doesn't work with modern environments. Or if it depends on long abandoned frameworks. Or if the business grows but the old implementation scales badly or not at all. Or if it depends on components that incur licensing fees that become prohibitively expensive when it's scaled up. Or if there are other legacy systems on different technical baselines that it could work with better after being rebuilt on the same base. Or if its tech simply requires more maintenance than an alternative, thus binding dev resources the company could otherwise use more productively. There are alot of reasons why maintaining an old system may be an undesireable move in the long run, that have exactly zero to do with the competence of the developers involved.
  - hinkley 3y ago
    You say that as if these events are unfortunate accidents instead of lack of technical leadership. I’ve met quite a few “unlucky” people in my life and what nearly all of them had in common was the inability to connect their actions and inactions to consequences. They were blindsided by predictable outcomes over, and over, and over again. Eventually the people who could actually help you get tired of your drama and move on, and then you’re left in an echo chamber where your narrative makes sense. I’ve spent a lot of time on this job thinking about the thoughts and plans of the people who have left. If our vertical were more compelling I believe we could make a better product with the people who have left than with the people who stayed. Even considering the lack of depth in domain knowledge. There’s a lot of things that don’t change because they were the right thing to do ten years ago. That’s an explanation for how we arrived here, not a reason to stay.
delusional 3y ago
>On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future. That's going to be very difficult, especially when you then also have to consider that the changes you could do could REDUCE the cost of maintaining it. If you're only ever appending code, then the cost to maintain can quickly skyrocket. If you're also diligent about removing the features that you don't need, there should be no significant difference at the limit. Basically, assuming you are properly maintaining the existing system, you should be continually refactoring it to be what you would build if you started from scratch. In that view, the cost of maintaining it will be identical, and the only cost that matters is the cost of bringing the existing system into alignment with what you would build now.
jt2190 3y ago
> And many of those costs have a nasty tendency to remain hidden until they suddenly don't, and at that point, people often already expended inordinate amounts of resources on them. Any business that employs software developers knows exactly how much it costs to employ them. If that math doesn’t work then the software developers loose their jobs. This basically establishes a baseline for “value” that must be delivered, at minimum. Above the baseline, software devs are left to their own devices: There will be no hard accounting of weather development effort is “worth it”, rather it’ll mostly be about whether people feel like it was. (This is sort of the origin of “too much money spoils things”.) As long as the effort doesn’t destroy everything, it can be argued that it was a success! So, the “hidden” costs are actually “bearable costs” because the business is just fine. The costs are “revealed” only when they’re no longer bearable. Ironically, well designed software “hides” the costs much longer than poorly designed, so what is missing is that we don’t have a great way of assigning value to in-house developed software that “just works”. Developers don’t even really think about it much because they get paid for writing code. I think that’s why the advice… > Use what already exists … becomes very hard, in practice, for devs to follow, even though it’s excellent advice. It’s a problem for management to solve.

PartiallyTyped 3y ago

Personal example I am living through. By the estimates of another team, it will take 2-3 months to build a wrapper around their codebase (it is that entangled) and throw that in EC2. The whole project will become infested with that codebase and those issues because as we all know, a “temporary fix” is never temporary. The codebase doesn’t cover anywhere near what we have in mind for features and extensibility is … yeah.

elygre 3y ago

I notice that on your “one side”, you have the cost of the rebuild — but not the “projected cost of keeping this thing and maintaining it”. That’s a common fallacy of programming: the existing code is convoluted and hard ti maintain, but the new code I would replace it with will be much better and much cheaper to maintain.

usrbinbash 3y ago
That's a very good point you make there, and I should have mentioned that in my post. Yes, the cost of the rebuild itself, PLUS it's own maintenance, fit with the rest of the codebase, extensibility and so on, must be considered in that equation. I glanced over that, because usually the rationale for a good rebuild is an improvement regarding exactly these metrics.
djbusby 3y ago
Yea, they(we) always say the new code will be better. Yet, eventually the new code becomes the old code and the cycle repeats. Assumptions and Environment change. New becomes old. And old has maintenance cost.
XorNot 3y ago
Conversely...in a lot of cases you can reasonably project it's likely you won't be maintaining it. So what you're really projecting is how much trouble you expect to save yourself for your forseeable remaining time at the company.
kmoser 3y ago
In addition to projected cost to maintain, there is also the potential ill will you are continuing to generate with your customers if the existing buggy/legacy system affects them. Your reputation with your customers matters. This is one of the biggest factors I see companies ignore all the time.

m3kw9 3y ago

Reusing code cause issues if you are not very careful because if not checked people often keep adding to it or someone modified it for their use case and breaks others. Many times is just better not to reuse

edgyquant 3y ago
This is what tests are for

dfcowell 3y ago

This is a really good addition, and something I wish I’d thought to cover. I’ve added a link back to this HN thread to the post so that people who find it from other sources can benefit from your perspective!

goto11 3y ago

> when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Only developers who love greenfield or need a new framework on the CV would suggest a company could lose money by not rebuilding. If the developers are not competent enough to write maintainable code or maintain existing code, then you will have exactly the same difficulties after the rebuild. If they are competent enough to write maintainable code and maintain existing code, then you have no need for a rebuild. Just adapt and extend the existing code to meet the new requirements.

usrbinbash 3y ago
> If the developers are not competent enough to write maintainable code or maintain existing code Or if the old system simply doesn't work with modern environments. Or if it depends on long abandoned frameworks. Or if the business grows but the old implementation scales badly or not at all. Or if it depends on components that incur licensing fees that become prohibitively expensive when it's scaled up. Or if there are other legacy systems on different technical baselines that it could work with better after being rebuilt on the same base. Or if its tech simply requires more maintenance than an alternative, thus binding dev resources the company could otherwise use more productively. There are alot of reasons why maintaining an old system may be an undesireable move in the long run, that have exactly zero to do with the competence of the developers involved.
- hinkley 3y ago
  You say that as if these events are unfortunate accidents instead of lack of technical leadership. I’ve met quite a few “unlucky” people in my life and what nearly all of them had in common was the inability to connect their actions and inactions to consequences. They were blindsided by predictable outcomes over, and over, and over again. Eventually the people who could actually help you get tired of your drama and move on, and then you’re left in an echo chamber where your narrative makes sense. I’ve spent a lot of time on this job thinking about the thoughts and plans of the people who have left. If our vertical were more compelling I believe we could make a better product with the people who have left than with the people who stayed. Even considering the lack of depth in domain knowledge. There’s a lot of things that don’t change because they were the right thing to do ten years ago. That’s an explanation for how we arrived here, not a reason to stay.

delusional 3y ago

>On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future. That's going to be very difficult, especially when you then also have to consider that the changes you could do could REDUCE the cost of maintaining it. If you're only ever appending code, then the cost to maintain can quickly skyrocket. If you're also diligent about removing the features that you don't need, there should be no significant difference at the limit. Basically, assuming you are properly maintaining the existing system, you should be continually refactoring it to be what you would build if you started from scratch. In that view, the cost of maintaining it will be identical, and the only cost that matters is the cost of bringing the existing system into alignment with what you would build now.

jt2190 3y ago

> And many of those costs have a nasty tendency to remain hidden until they suddenly don't, and at that point, people often already expended inordinate amounts of resources on them. Any business that employs software developers knows exactly how much it costs to employ them. If that math doesn’t work then the software developers loose their jobs. This basically establishes a baseline for “value” that must be delivered, at minimum. Above the baseline, software devs are left to their own devices: There will be no hard accounting of weather development effort is “worth it”, rather it’ll mostly be about whether people feel like it was. (This is sort of the origin of “too much money spoils things”.) As long as the effort doesn’t destroy everything, it can be argued that it was a success! So, the “hidden” costs are actually “bearable costs” because the business is just fine. The costs are “revealed” only when they’re no longer bearable. Ironically, well designed software “hides” the costs much longer than poorly designed, so what is missing is that we don’t have a great way of assigning value to in-house developed software that “just works”. Developers don’t even really think about it much because they get paid for writing code. I think that’s why the advice… > Use what already exists … becomes very hard, in practice, for devs to follow, even though it’s excellent advice. It’s a problem for management to solve.