4 ms·

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only sma

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only smart person to work on a codebase, and it's more common that another smart person did what they did for a reason, than that I'm a genius who knows better than they did.

samus 2y ago
Sometimes there were reasons, but they were not necessarily good ones. Like these: - time pressure, leading to just making it work and not caring about edge cases, which were bolted on later. Or maybe never at all. And naturally, there is no useful testsuite. - the prototype ended up in production - a refactoring happened, but there was no follow-up into other areas of the code base - features changed, but the code is still influenced by the necessities of the old way it worked. Similarly, for changing technical circumstances - code was copy-pasted or was worked on by too many people - code was herded too long by the same person and now, to put it nicely, bears traces of their bespoke coding style Chesterton's Fence is still very relevant, therefore I'd still err on the side of writing a lot of high-level tests before touching anything.
- kaffekaka 2y ago
  All of these, I have been guilty of. Fairly recently, too.
- yxhuvud 2y ago
  And not to forget: business realities change over time, but it is not always the code follow.
Capricorn2481 2y ago
Such a rare opinion on HN unfortunately. But you're correct.
Terr_ 2y ago
Kind of light fighting against the human tendency [0] to blame the failings of others on their core character rather than the situations they are in, and vice-versa for oneself. [0] https://en.wikipedia.org/wiki/Fundamental_attribution_error https://en.wikipedia.org/wiki/Fundamental_attribution_error

4 ms·

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only sma

by kerkeslager 2y ago

samus 2y ago
Sometimes there were reasons, but they were not necessarily good ones. Like these: - time pressure, leading to just making it work and not caring about edge cases, which were bolted on later. Or maybe never at all. And naturally, there is no useful testsuite. - the prototype ended up in production - a refactoring happened, but there was no follow-up into other areas of the code base - features changed, but the code is still influenced by the necessities of the old way it worked. Similarly, for changing technical circumstances - code was copy-pasted or was worked on by too many people - code was herded too long by the same person and now, to put it nicely, bears traces of their bespoke coding style Chesterton's Fence is still very relevant, therefore I'd still err on the side of writing a lot of high-level tests before touching anything.
- kaffekaka 2y ago
  All of these, I have been guilty of. Fairly recently, too.
- yxhuvud 2y ago
  And not to forget: business realities change over time, but it is not always the code follow.
Capricorn2481 2y ago
Such a rare opinion on HN unfortunately. But you're correct.
Terr_ 2y ago
Kind of light fighting against the human tendency [0] to blame the failings of others on their core character rather than the situations they are in, and vice-versa for oneself. [0] https://en.wikipedia.org/wiki/Fundamental_attribution_error https://en.wikipedia.org/wiki/Fundamental_attribution_error