4 ms·

Actually I feel it is the opposite of that. Existing code can be battle tested and reliable, with lots of unforeseen bugs encountered and fixed. But those bugf

Actually I feel it is the opposite of that. Existing code can be battle tested and reliable, with lots of unforeseen bugs encountered and fixed. But those bugfixes made the old code difficult to work with, and rather than take the time to understand it, new code is developed instead with a whole new set of bugs (many having been solved previously). Working with old code is unexciting and unsexy anyway, and it is unlikely to advance your career. And so the cycle continues.

ssivark 6y ago
The contrast between the two perspectives depends on the relative emphasis between human understanding of the domain knowledge and accumulated domain knowledge in pre-existing code. Biased by the domains I have worked in, I feel that we undervalue the human ability to figure things out and create good solutions, and overvalue code that is available for “free” even though it addresses a problem only tangentially related to what one is doing. My comment pertains mostly to such situations. In situations where the opposite is true (the domain in mostly static, and the old code is a good fit, and we don’t trust human intelligence to figure things out and solve problems), “stable” code is certainly valuable.
- sseagull 6y ago
  That's fair. I come from a scientific computing background, where old code is sometimes treasured, even though there is increasing pressure to "modernize". But the older code often has several decades worth of testing across many use cases, which is hard to beat.
- Falkon1313 6y ago
  I agree with both sides to a degree. The tendency to use monster truck wheels on a shopping cart or vice-versa (because reinventing the wheel is considered evil) makes software a mess, but so does throwing out years of debugging subtle/rare conditions. Code reuse however also tends to add tons of bloat and potentially bugs caused by things that aren't even relevant to the current usage. Not to mention all the added complexity of having to add another layer over to translate the current terms into the terms the re-used code understands and then override what it does and translate the output. There are some cases where it would be preferable to preserve the embedded domain knowledge, but in many cases the cost of 'reinventing the wheel' would be less than adapting an unfit wheel.

ssivark 6y ago

The contrast between the two perspectives depends on the relative emphasis between human understanding of the domain knowledge and accumulated domain knowledge in pre-existing code. Biased by the domains I have worked in, I feel that we undervalue the human ability to figure things out and create good solutions, and overvalue code that is available for “free” even though it addresses a problem only tangentially related to what one is doing. My comment pertains mostly to such situations. In situations where the opposite is true (the domain in mostly static, and the old code is a good fit, and we don’t trust human intelligence to figure things out and solve problems), “stable” code is certainly valuable.

sseagull 6y ago
That's fair. I come from a scientific computing background, where old code is sometimes treasured, even though there is increasing pressure to "modernize". But the older code often has several decades worth of testing across many use cases, which is hard to beat.
Falkon1313 6y ago
I agree with both sides to a degree. The tendency to use monster truck wheels on a shopping cart or vice-versa (because reinventing the wheel is considered evil) makes software a mess, but so does throwing out years of debugging subtle/rare conditions. Code reuse however also tends to add tons of bloat and potentially bugs caused by things that aren't even relevant to the current usage. Not to mention all the added complexity of having to add another layer over to translate the current terms into the terms the re-used code understands and then override what it does and translate the output. There are some cases where it would be preferable to preserve the embedded domain knowledge, but in many cases the cost of 'reinventing the wheel' would be less than adapting an unfit wheel.