> The memory goes bad because they write useless logs to a chip, and it eventually fails.
I worked for a $ ~billions revenue software storage vendor who had the exact same issue (excessive logging wearing out under-spec'd flash drives).
I worked for a $ ~billions revenue software storage vendor who had the exact same issue (excessive logging wearing out under-spec'd flash drives).
Datadog was costing several thousand euros per month despite near-absent customer traffic. But the name made finally sense because all the data in there was absolute dog shit from reboots.
So yeah too much logging can be bad.
I definitely think that teams should think about what to log. Otherwise go with a live image kind of system like Smalltalk of LISP. The whole event sourcing paradigm and trying to just log everything and look at it later strike me as a poor reconstruction of that concept.
There is a tragic aspect to the "Worse is Better" essay that I see play out everywhere: there is a way to do something correctly but just throwing something together wins the race to market. Winner takes all and we're stuck with ossified bad decisions from the past. The idea that we can fix it later is just a lie. You can't do the foundation later, you'll be stuck with a structurally unsound edifice and forever holding it together under a completely unnecessary cognitive load.
And I also agree about worse is better. To me the most tragic part is that "worse" has become almost as costly as doing "The Right Thing", mostly due to the extreme flexibility and rush to the market from vendors and libraries. Our foundations weren't as sketchy when the concept was invented.
The guy basically answered "Oh, same. I just ask for people to do microservices because that's how the CTO wants".
These kind of problems only happen years after the software roll out so no one cares when you are under time pressure.