5 ms·

Am I the only one in the IT adjacent world who thinks the inverse of this is the larger problem (churn, NIH, reinventing the wheel) in software today?

dano 7y ago
No, you are not the only one. The quest for the new shiny thing is stronger than ever today. New frameworks, new languages, silver bullets everywhere. Good decision making frameworks are in tremendous need in the technology world to help everyone understand the ramifications of the choices they're trying to make.
- charlieflowers 7y ago
  > Good decision making frameworks are in tremendous need in the technology Can you/anyone recommend any?
32gbsd 7y ago
You dont rewrite modern software.
- dfox 7y ago
  That depends by what you mean by “modern”. And the age of the system of question is completely irrelevant to whether it is or isn't an unmaintainable legacy mess.
  - 32gbsd 7y ago
    wait a minute I thought legacy was used to refer to old pre-cloud pre-serverless pre-javascript software? Everything written nowadays is modern and hence you just replace it with more modern stuff. re-writing it is often difficult because of its modern layers.
    - fourthark 7y ago
      I hope this is satire, but I’m not sure if it is.
      - morgancmartin 7y ago
        r/programmingcirclejerk would have a field day with it, that's for certain.
    - exdsq 7y ago
      Any code that’s not Serverless JS needs to be rewritten
on_and_off 7y ago
oh you are not the only one at all ! I mostly work in the android world and the chase for the new and shiny is real. I see some new libraries get a lot of traction seemingly only because they are written in kotlin/coroutines, not because they offer a better solution (for the one I have in mind, they did not even bother trying to do a benchmark to compare it with the existing solutions). The thing is, the Android dev ecosystem got WAY better in some aspects. Having moved to some of the new and shiny, well implemented MVI/MVVM architectures backed by Rx or Flow are very robust and give a good framework to develop on. You still have to fight back against the zealots yelling that solution x that works just fine should be replaced by solution y even though it would take months of engineering work and does not really improve anything you care about (e.g. a 5% diminution of bytecode size is not something that's worth spending weeks on, or a network stack that hand wavingly 'improves performances' with no benchmark made to actually ascertain where our hot paths are) PS.: for the parts that got worse : the build system and Android Studio failed to scale quickly enough to keep up with the enormous increase of build complexity. As a result they are slowly become less and less useable for large projects.
- afarrell 7y ago
  Part of this is that many software engineers are bad at advocating for what they care about. One way of being bad at advocacy is to try to point to whatever has numbers, even if those numbers don't ultimately matter. Sadly, it takes a lot more skill and courage to say the following in a way that other stakeholders care about: "We should use this tool because when I started using it, data flows were clear in a way that finally silenced some of the anxiety that I don't know what the fuck I'm doing and I am going to ruin everything."
  - afarrell 7y ago
    I've started a separate thread to talk about that communication skill here: https://news.ycombinator.com/item?id=22352477 https://news.ycombinator.com/item?id=22352477
scarface74 7y ago
I’ve had to learn not only reinventing a wheel created by someone else before I came to a company, but also reinventing the wheel that I created when I didn’t know what I know now.
mikekchar 7y ago
I specialise in legacy code. Not that I'm opposed to doing a greenfield project now and again, but I genuinely enjoy working with legacy code. It's a fun challenge and the "stink of old" on it keeps the must-have-shiny people away for the most part. However, it's always a challenge. For example, sometimes you have subsystems that are begging to be retired. For example, on one system we're maintaining about 20 KLOC of GWT code. For the last 10 years or so, it hasn't really been worth moving away from it, but there will be a day (that is rapidly approaching, I think) where the cost of supporting a mostly abandoned Java framework that compiles into JS outweighs the risk and cost of slowly replacing it. There's a real difference between being pissed off with the choices your predecessors made, or lusting after the new, hot framework and saying: nope... this just isn't viable any more. Planning that transition isn't easy either. Again, it's one of the reasons I enjoy this kind of work. And sometimes, you even just decide that you're going to work with what you've got. Ironically, though, this usually involves more churn, NIH and reinventing the wheel because code written 20 or 30 years ago did not have the facilities that we desire in modern development. You think, I'd love to enjoy the benefits of that new framework, but there ain't no way that we'll be able to use it. How do I get the benefits using the code I already have? Answer: you study what other people are doing and you build the same damn thing in your environment. Nobody builds the new-shiny for old stuff so if you want it, you have to build it yourself. I enjoy bonsai trees. As trees grow, the branches become out of scale with the trunks. You can imagine that if your trunk is the size of a pencil, it doesn't take long for the branches to catch up. So if you want a tree that is in scale, you are constantly having to prune off the branches and grow new ones. There is a saying that a bonsai tree is never finished until it is done. Code is the same way. There is no such thing as avoiding churn -- unless you are truly trying to kill off your project. You always have to prune off branches and grow new ones, otherwise development will slowly grind to a halt -- the challenge of adding functionality without changing the code base getting to be more and more complex. But if you prune your branches before they grow you will end up with a stick in a pot. Or if you decide that you want to grow out every bud that pops out, then you will have an impenetrable mass of confusion. Deciding which branches to grow and which branches to prune, unfortunately requires good taste.

dano 7y ago

No, you are not the only one. The quest for the new shiny thing is stronger than ever today. New frameworks, new languages, silver bullets everywhere. Good decision making frameworks are in tremendous need in the technology world to help everyone understand the ramifications of the choices they're trying to make.

charlieflowers 7y ago
> Good decision making frameworks are in tremendous need in the technology Can you/anyone recommend any?

32gbsd 7y ago

You dont rewrite modern software.

dfox 7y ago
That depends by what you mean by “modern”. And the age of the system of question is completely irrelevant to whether it is or isn't an unmaintainable legacy mess.
- 32gbsd 7y ago
  wait a minute I thought legacy was used to refer to old pre-cloud pre-serverless pre-javascript software? Everything written nowadays is modern and hence you just replace it with more modern stuff. re-writing it is often difficult because of its modern layers.
  - fourthark 7y ago
    I hope this is satire, but I’m not sure if it is.
    - morgancmartin 7y ago
      r/programmingcirclejerk would have a field day with it, that's for certain.
  - exdsq 7y ago
    Any code that’s not Serverless JS needs to be rewritten

on_and_off 7y ago

oh you are not the only one at all ! I mostly work in the android world and the chase for the new and shiny is real. I see some new libraries get a lot of traction seemingly only because they are written in kotlin/coroutines, not because they offer a better solution (for the one I have in mind, they did not even bother trying to do a benchmark to compare it with the existing solutions). The thing is, the Android dev ecosystem got WAY better in some aspects. Having moved to some of the new and shiny, well implemented MVI/MVVM architectures backed by Rx or Flow are very robust and give a good framework to develop on. You still have to fight back against the zealots yelling that solution x that works just fine should be replaced by solution y even though it would take months of engineering work and does not really improve anything you care about (e.g. a 5% diminution of bytecode size is not something that's worth spending weeks on, or a network stack that hand wavingly 'improves performances' with no benchmark made to actually ascertain where our hot paths are) PS.: for the parts that got worse : the build system and Android Studio failed to scale quickly enough to keep up with the enormous increase of build complexity. As a result they are slowly become less and less useable for large projects.

afarrell 7y ago
Part of this is that many software engineers are bad at advocating for what they care about. One way of being bad at advocacy is to try to point to whatever has numbers, even if those numbers don't ultimately matter. Sadly, it takes a lot more skill and courage to say the following in a way that other stakeholders care about: "We should use this tool because when I started using it, data flows were clear in a way that finally silenced some of the anxiety that I don't know what the fuck I'm doing and I am going to ruin everything."
- afarrell 7y ago
  I've started a separate thread to talk about that communication skill here: https://news.ycombinator.com/item?id=22352477 https://news.ycombinator.com/item?id=22352477

scarface74 7y ago

I’ve had to learn not only reinventing a wheel created by someone else before I came to a company, but also reinventing the wheel that I created when I didn’t know what I know now.

mikekchar 7y ago

I specialise in legacy code. Not that I'm opposed to doing a greenfield project now and again, but I genuinely enjoy working with legacy code. It's a fun challenge and the "stink of old" on it keeps the must-have-shiny people away for the most part. However, it's always a challenge. For example, sometimes you have subsystems that are begging to be retired. For example, on one system we're maintaining about 20 KLOC of GWT code. For the last 10 years or so, it hasn't really been worth moving away from it, but there will be a day (that is rapidly approaching, I think) where the cost of supporting a mostly abandoned Java framework that compiles into JS outweighs the risk and cost of slowly replacing it. There's a real difference between being pissed off with the choices your predecessors made, or lusting after the new, hot framework and saying: nope... this just isn't viable any more. Planning that transition isn't easy either. Again, it's one of the reasons I enjoy this kind of work. And sometimes, you even just decide that you're going to work with what you've got. Ironically, though, this usually involves more churn, NIH and reinventing the wheel because code written 20 or 30 years ago did not have the facilities that we desire in modern development. You think, I'd love to enjoy the benefits of that new framework, but there ain't no way that we'll be able to use it. How do I get the benefits using the code I already have? Answer: you study what other people are doing and you build the same damn thing in your environment. Nobody builds the new-shiny for old stuff so if you want it, you have to build it yourself. I enjoy bonsai trees. As trees grow, the branches become out of scale with the trunks. You can imagine that if your trunk is the size of a pencil, it doesn't take long for the branches to catch up. So if you want a tree that is in scale, you are constantly having to prune off the branches and grow new ones. There is a saying that a bonsai tree is never finished until it is done. Code is the same way. There is no such thing as avoiding churn -- unless you are truly trying to kill off your project. You always have to prune off branches and grow new ones, otherwise development will slowly grind to a halt -- the challenge of adding functionality without changing the code base getting to be more and more complex. But if you prune your branches before they grow you will end up with a stick in a pot. Or if you decide that you want to grow out every bud that pops out, then you will have an impenetrable mass of confusion. Deciding which branches to grow and which branches to prune, unfortunately requires good taste.