3 ms·

I could replace "Kubernetes" with GraphQL/React/Next in my world. All, of course, to migrate a perfectly functioning app (mostly CRUD) and doesn't need any of

I could replace "Kubernetes" with GraphQL/React/Next in my world. All, of course, to migrate a perfectly functioning app (mostly CRUD) and doesn't need any of the tradeoffs given by GraphQL or an interactive frontend. The longer I am in this industry the more I see people in charge have no idea of what they're doing.

Traubenfuchs 3y ago
People are never rewarded for keeping things running. They are rewarded for change, as long as they can at least pretend it is (or will be) paying off.
- Draiken 3y ago
  Definitely agree. But it's not only about keeping things running though. People want to fix issues by rewriting everything because it's gonna look good on their resumé and it's "easier". You don't have to deal with the old stuff. It saddens me because improving code (especially one that changes often) is absolutely crucial, but we seem to never bite the bullet and improve the existing code, instead opting to rewrite the entire world in never-ending projects. After a company gets burned by one of these rewrites, they often become averse to any refactoring and the few legitimate rewrites that need to happen. We spend all our influence capital on useless projects and then wonder why our industry is so often viewed as unprofessional and amateurish.
  - Traubenfuchs 3y ago
    > It saddens me because improving code (especially one that changes often) is absolutely crucial It has burned me and it has burned others. Just doing cosmetic refactorings alone me and others I have observed caused new bugs. Let alone doing architectural or other "deeper" refactorings. At this point I pretty much refuse touching anything not related to my ticket, everything else is a risk to my reputation. When I see junior developers take on unrelated refactorings, I let them fly too close to the sun, they will learn through the pain. Last thing I did a few years ago was changing a weird boolean field that could be null. I thought it would be smarter to default it to false, client team told me it was fine. We then found out in production that very old clients actually had different logic based on true, false AND null. I got pinged in my free time, it ruined the date I was on and thus at least the whole day. In a perfect world you have CDC and all the testing in the world, but in reality you just don‘t.
    - Draiken 3y ago
      Yeah, I've been there too. But the problem is that avoiding those completely and then only resorting to rewrites, costs magnitudes more and it's just as buggy. Many times it introduces new issues. Doing small incremental improvements is, most of the time, the best way to improve. But because in general there's no incentive to have even a base level of quality in software, the incentive is towards rewriting and dealing with all the issues after the fact. It really makes me sad.

Traubenfuchs 3y ago

People are never rewarded for keeping things running. They are rewarded for change, as long as they can at least pretend it is (or will be) paying off.

Draiken 3y ago
Definitely agree. But it's not only about keeping things running though. People want to fix issues by rewriting everything because it's gonna look good on their resumé and it's "easier". You don't have to deal with the old stuff. It saddens me because improving code (especially one that changes often) is absolutely crucial, but we seem to never bite the bullet and improve the existing code, instead opting to rewrite the entire world in never-ending projects. After a company gets burned by one of these rewrites, they often become averse to any refactoring and the few legitimate rewrites that need to happen. We spend all our influence capital on useless projects and then wonder why our industry is so often viewed as unprofessional and amateurish.
- Traubenfuchs 3y ago
  > It saddens me because improving code (especially one that changes often) is absolutely crucial It has burned me and it has burned others. Just doing cosmetic refactorings alone me and others I have observed caused new bugs. Let alone doing architectural or other "deeper" refactorings. At this point I pretty much refuse touching anything not related to my ticket, everything else is a risk to my reputation. When I see junior developers take on unrelated refactorings, I let them fly too close to the sun, they will learn through the pain. Last thing I did a few years ago was changing a weird boolean field that could be null. I thought it would be smarter to default it to false, client team told me it was fine. We then found out in production that very old clients actually had different logic based on true, false AND null. I got pinged in my free time, it ruined the date I was on and thus at least the whole day. In a perfect world you have CDC and all the testing in the world, but in reality you just don‘t.
  - Draiken 3y ago
    Yeah, I've been there too. But the problem is that avoiding those completely and then only resorting to rewrites, costs magnitudes more and it's just as buggy. Many times it introduces new issues. Doing small incremental improvements is, most of the time, the best way to improve. But because in general there's no incentive to have even a base level of quality in software, the incentive is towards rewriting and dealing with all the issues after the fact. It really makes me sad.