This is probably just my personal feeling, but the article though well written, left me feeling it missed the point - age does not always imply wisdom, the ability to learn from your mistakes and reflect on how you can improve your work is probably much more valuable.
It wasn’t bad enough to downvote - but it wasn’t good enough in my opinion to upvote….hope that explains my comment better - I expect a lot from the articles on Lobsters :~)
I read the start of the article with interest, and then all of a sudden it ended. Just when I thought it was going to move past the abstract introduction, that was actually the conclusion!
“Do you want to make things better?” Yes.
…
…
“Oh, that was all.”
How is it that code turns into legacy code? How do we repair it? (Fire, and lots of it, but I’d like to hear some others' approaches.)
This article feels like it doesn’t say anything very specific to software, it just compares the accumulation of legacy code to hoarding, analogy which I’d rate as at beast “OK”. Both have the slippery slop effect and both involve the reasoning that more stuff involves more value. But that’s about where the analogy stops. Most hoarders are individuals who somewhat pathologically accumulate more stuff than they have space for until the situation becomes unbearable - their accumulated stuff provide no value to them fairly soon in the process. Most legacy code is the product of a chain of bureaucratic decisions, each partly rational and partly irrational. There aren’t many individuals with accumulated legacy code (though there are a few but they usually aren’t the focus when one tries to solve “the problem of legacy code”). The results of legacy code can be high costs and limits to a company’s ability to change processes and act on opportunities quickly. BUT legacy code, as a rule, provides significant value to a company. That’s because software is different than books or cabinets or whatever it is real-life hoarders hoard. Software takes virtually no space and continues to be useful after you’ve accumulate a huge amount of “horrible code” - if the horrible code happens to be good enough to accomplish something, it can continue being used a long, long time.
You could say Legacy Code is technical debt that has now gone to collections. But unlike hoarding, there were calculations all along the way that got you there and for a number of situations perhaps being there is rational in the sense of being the decision that brings the enterprise the most income.
And the thing is the reference in the other article: “ If you decide that organizing your system isn’t worth the effort, you’ll wind up as a Code Hoarder.” - was a kind of “instead of an argument” sort of response. “If you don’t do X, you’ll be bad is why you should do X”
I also came across this article from reading Does organisation matter? but felt it was not a good lobste.rs article.
Really? Could you explain why?
Also, that’s an interesting coincidence because I actually just found this article while looking for something else. Small internet. :)
This is probably just my personal feeling, but the article though well written, left me feeling it missed the point - age does not always imply wisdom, the ability to learn from your mistakes and reflect on how you can improve your work is probably much more valuable.
It wasn’t bad enough to downvote - but it wasn’t good enough in my opinion to upvote….hope that explains my comment better - I expect a lot from the articles on Lobsters :~)
I read the start of the article with interest, and then all of a sudden it ended. Just when I thought it was going to move past the abstract introduction, that was actually the conclusion!
“Do you want to make things better?” Yes.
…
…
“Oh, that was all.”
How is it that code turns into legacy code? How do we repair it? (Fire, and lots of it, but I’d like to hear some others' approaches.)
I have to agree with fcbsd.
This article feels like it doesn’t say anything very specific to software, it just compares the accumulation of legacy code to hoarding, analogy which I’d rate as at beast “OK”. Both have the slippery slop effect and both involve the reasoning that more stuff involves more value. But that’s about where the analogy stops. Most hoarders are individuals who somewhat pathologically accumulate more stuff than they have space for until the situation becomes unbearable - their accumulated stuff provide no value to them fairly soon in the process. Most legacy code is the product of a chain of bureaucratic decisions, each partly rational and partly irrational. There aren’t many individuals with accumulated legacy code (though there are a few but they usually aren’t the focus when one tries to solve “the problem of legacy code”). The results of legacy code can be high costs and limits to a company’s ability to change processes and act on opportunities quickly. BUT legacy code, as a rule, provides significant value to a company. That’s because software is different than books or cabinets or whatever it is real-life hoarders hoard. Software takes virtually no space and continues to be useful after you’ve accumulate a huge amount of “horrible code” - if the horrible code happens to be good enough to accomplish something, it can continue being used a long, long time. You could say Legacy Code is technical debt that has now gone to collections. But unlike hoarding, there were calculations all along the way that got you there and for a number of situations perhaps being there is rational in the sense of being the decision that brings the enterprise the most income.
And the thing is the reference in the other article: “ If you decide that organizing your system isn’t worth the effort, you’ll wind up as a Code Hoarder.” - was a kind of “instead of an argument” sort of response. “If you don’t do X, you’ll be bad is why you should do X”