3 ms·

Good write-up. I've been observing this phenomenon for years and I think that one of the main causes is poor cost estimation by developers (or, often, no cost e

by rumcajz 12y ago

Good write-up. I've been observing this phenomenon for years and I think that one of the main causes is poor cost estimation by developers (or, often, no cost estimation). The new project lead asks management to allow him to re-write the project. It's a 10 manyear task so the management declines. At that point he decides to do the changes in gradual manner, completely ignoring the fact that it's still a 10 manyear task, while, realistically, his team can spend 2 manmonths a year on refactoring. Thus, the re-write will be accomplished in 60 years. The same pattern repeats with the next project lead and so on.

angersock 12y ago
There's that wonderful point in a project where you can point--point directly at!--a fix to a fix to make legacy thing work. I love that point. That's the point I start looking for new work and resenting my forerunners. "second system" syndrome is very real, but nobody in management ever seems to appreciate "Look, technology has progressed in the last five years since this was written...we can do more with less, pleeeeaaaase let us fix this.". Nobody looks forward to working with legacy code. The business logic is usually wrong, the business itself has changed, the original developers are gone, the market talent composition has changed, etc. I'd honestly rather see a business embrace the ablative nature of code and instead build itself with the assumption that, every 2-3 years, chunks will be rewritten. This is an argument in favor of services and better documentation and tests, by the way. EDIT: And even worse is when the manager/CTO/whatever admits that the code is going to need rewriting--but not yet. Because that means that a) you're going to be wasting effort temporarily fixing something you know will be thrown out and b) tacitly admitting that they are too scared of change to embrace it and too short-sighted to figure out how to balance business requirements with technical debt. I've been burned by that multiple times. A man-month of unpaid overtime for rewrites, not a nano-second for legacy support!
- usea 12y ago
  >I'd honestly rather see a business embrace the ablative nature of code and instead build itself with the assumption that, every 2-3 years, chunks will be rewritten >And even worse is [...] you're going to be wasting effort temporarily fixing something you know will be thrown out Can you reconcile these two points for me? I fear I may be misunderstanding you. It sounds like you're arguing in favor of treating code as a transient thing, but then lamenting having to write something that won't last.
  - angersock 12y ago
    Sure thing. The subtle difference (not well articulated by me, I suppose) is that in one case, you are given the go ahead to go and rewrite everything to conform to, say, an interface spec or API or whatever. This year's implementation or architecture may be scrapped, but then you get a cleanish slate. In the latter case, what's happening is you are usually building an adapter over something that exists, instead of throwing it away completely. What then happens is that there is a lot of stress involved ("Is this wrapping correctly?", "Does this still do what it used to?", "Have my tests covered all the use cases?", "Wait, fuck, this original thing never even had tests...so aren't my tests are kind of pissing in the wind?", etc.) and then inevitably the push is to fix the fixes, and then fix the fixes' fixes, and so on. And sometimes that's unavoidable (maybe the legacy code is, oh I don't know, numerical simulation of a heat-exchanger in Fortan77 that was cutting edge and now the original author is quite dead and buried). But, the painful thing (as mentioned) is when the person in charge even admits that the whole thing will be rewritten anyways. In that case, why the fuck is the rewrite being put off? It signals a lack of faith in the development team, and a lack of prior planning to deal with downtime or other issues coming up.
- ulisesrmzroche 12y ago
  No one should be clocking any underpaid overtime no matter what, that's just crazy talk. I'd rather take the legacy code than deal with that.
  - nnq 12y ago
    Unfortunately your otherwise correct and very healthy mentality on work/pay ethics is only fashionable in US + Canada + Australia + parts of Europe. The whole rest of the world (that happens to include more than 60% of the planet's population btw...) has very different views on things. And considering that return on capital grows much faster than return on labor, things are not improving worldwide, actually the reverse... And keep in the mind that software industry tends to be on the "fair" side of the fence regarding work/pay ethics everywhere in the world... all other professions are much worse. And sticking to the subject: lots of programmers I know would unfortunately choose the unpaid overtime instead of the working with legacy code, and, unfortunately, I've even witnessed discussions where the programmers were more or less directly offering to put in the unpaid/unclocked overtime just to convince the management to let them do the fucking rewrite from scratch! ...the world in general is much crazier than you think, and you "crazy talk" can very easily turn into "they way we usually do things down here", unfortunately.

by rumcajz 12y ago

angersock 12y ago

There's that wonderful point in a project where you can point--point directly at!--a fix to a fix to make legacy thing work. I love that point. That's the point I start looking for new work and resenting my forerunners. "second system" syndrome is very real, but nobody in management ever seems to appreciate "Look, technology has progressed in the last five years since this was written...we can do more with less, pleeeeaaaase let us fix this.". Nobody looks forward to working with legacy code. The business logic is usually wrong, the business itself has changed, the original developers are gone, the market talent composition has changed, etc. I'd honestly rather see a business embrace the ablative nature of code and instead build itself with the assumption that, every 2-3 years, chunks will be rewritten. This is an argument in favor of services and better documentation and tests, by the way. EDIT: And even worse is when the manager/CTO/whatever admits that the code is going to need rewriting--but not yet. Because that means that a) you're going to be wasting effort temporarily fixing something you know will be thrown out and b) tacitly admitting that they are too scared of change to embrace it and too short-sighted to figure out how to balance business requirements with technical debt. I've been burned by that multiple times. A man-month of unpaid overtime for rewrites, not a nano-second for legacy support!

usea 12y ago
>I'd honestly rather see a business embrace the ablative nature of code and instead build itself with the assumption that, every 2-3 years, chunks will be rewritten >And even worse is [...] you're going to be wasting effort temporarily fixing something you know will be thrown out Can you reconcile these two points for me? I fear I may be misunderstanding you. It sounds like you're arguing in favor of treating code as a transient thing, but then lamenting having to write something that won't last.
- angersock 12y ago
  Sure thing. The subtle difference (not well articulated by me, I suppose) is that in one case, you are given the go ahead to go and rewrite everything to conform to, say, an interface spec or API or whatever. This year's implementation or architecture may be scrapped, but then you get a cleanish slate. In the latter case, what's happening is you are usually building an adapter over something that exists, instead of throwing it away completely. What then happens is that there is a lot of stress involved ("Is this wrapping correctly?", "Does this still do what it used to?", "Have my tests covered all the use cases?", "Wait, fuck, this original thing never even had tests...so aren't my tests are kind of pissing in the wind?", etc.) and then inevitably the push is to fix the fixes, and then fix the fixes' fixes, and so on. And sometimes that's unavoidable (maybe the legacy code is, oh I don't know, numerical simulation of a heat-exchanger in Fortan77 that was cutting edge and now the original author is quite dead and buried). But, the painful thing (as mentioned) is when the person in charge even admits that the whole thing will be rewritten anyways. In that case, why the fuck is the rewrite being put off? It signals a lack of faith in the development team, and a lack of prior planning to deal with downtime or other issues coming up.
ulisesrmzroche 12y ago
No one should be clocking any underpaid overtime no matter what, that's just crazy talk. I'd rather take the legacy code than deal with that.
- nnq 12y ago
  Unfortunately your otherwise correct and very healthy mentality on work/pay ethics is only fashionable in US + Canada + Australia + parts of Europe. The whole rest of the world (that happens to include more than 60% of the planet's population btw...) has very different views on things. And considering that return on capital grows much faster than return on labor, things are not improving worldwide, actually the reverse... And keep in the mind that software industry tends to be on the "fair" side of the fence regarding work/pay ethics everywhere in the world... all other professions are much worse. And sticking to the subject: lots of programmers I know would unfortunately choose the unpaid overtime instead of the working with legacy code, and, unfortunately, I've even witnessed discussions where the programmers were more or less directly offering to put in the unpaid/unclocked overtime just to convince the management to let them do the fucking rewrite from scratch! ...the world in general is much crazier than you think, and you "crazy talk" can very easily turn into "they way we usually do things down here", unfortunately.