Interesting indeed but the part that stuck with me the most is:
>> Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.
I read the article in 2016 and that phrase stuck with me ever since, I had never thought about it but it's such a simple and self evident fact but so easy to miss. It's a powerful concept to know. Both when writing and when refactoring code.
If you're working to get a certain task done at your job, yes I can see wanting to minimally touch the code.
If something gets bad enough, I will refactor the whole damn thing, but only at jobs where there are unit tests. If there are no unit tests, this truly becomes an impossible task and it's best not to touch anything you don't need to.
You have to have good tests if you ever want to tackle technical debt.
The point is not whether it is correct and necessary, but that its existence makes the argument that it is indeed so. What you mention is actually the insight that "it may not be". But you reach that idea _against_ the argument its presence is making.
That is, you find some code. Its presence says "I'm here for a reason", your answer of "maybe it's just because..." comes as, precisely, an _answer_ to that argument.
Neither the argument itself nor your answer are necessarily and always correct. This doesn't argue that point, just that the presence of a piece of code makes such an statement.
> We know that code represents effort expended, and we are very motivated to preserve the value of this effort. And, unfortunately, the sad truth is that the more complicated and incomprehensible the code, i.e. the deeper the investment in creating it, the more we feel pressure to retain it (the "sunk cost fallacy"). It's as if our unconscious tell us "Goodness, that's so confusing, it must have taken ages to get right. Surely it's really, really important. It would be a sin to let all that effort go to waste."
I should guess hamandchess and trufa are very young people, that are beginning in paid software. This explain they overvalue experienced programmers blogs.
The only thing experienced programmers truely value is profiling- write it, run it, measure it.
Advice is nice and all, but at the end of the day, even that new method to write code, gets to perform on the profiling table of your manager.
OO ?
Use it, run it against procedural or functional approach, measure it, decide.
Everything else is politics, religion and that one irresponsible guy who gets high on new things and away with it somehow, while touring companys.
>> Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.
I read the article in 2016 and that phrase stuck with me ever since, I had never thought about it but it's such a simple and self evident fact but so easy to miss. It's a powerful concept to know. Both when writing and when refactoring code.