in reply to Re^2: Legacy Code: "Dominoes = Bad"
in thread Legacy Code: "Dominoes = Bad"

Sure. But how much of the code you have written needs to be modified after 10 years? There's a lot of code that's being written that either won't survive 10 years, or, after having survived 10 years, will do another 10 years without modifications.

It's often not wise to pay an extra cost *now* just so you *may* save some costs in the future. The time you spend now to make code more maintainable cannot be spend on writing code that generates revenue. That's 10 years of revenue you'd have to compare against the savings of having to deal with harder to maintain code 10 years from now. Now, in some businesses coding for maintainability makes sense; I'm not arguing that. But I take issue with blanket statements - just because it sometimes makes sense, doesn't mean it always make sense.

Replies are listed 'Best First'.
Re^4: Legacy Code: "Dominoes = Bad"
by SuicideJunkie (Vicar) on Apr 27, 2011 at 13:55 UTC

    Around here, and I expect in most (if not all) cases of non-trivial code, "maintenance" starts during development. You don't have to wait 10 years before you suffer from poor maintainability, you don't even have to wait 10 days.

    If it is not maintainable, debugging is harder. Adding features (aka development) after a mere weekend is harder. And as such, meeting the deadline is harder.

      But what I have... and what I make it my business to deal with... is “ten year old code.”

      When a piece of software is “finished,” it doesn’t disappear.   The business requirements that led up to it do not become frozen in stone.   Why, “the web page” has already become “like, so 2009...”

      In its day, the code might have been brilliant.   It probably did reflect the technical requirements of its day, the technologies of its day, the best-practices choices of its day.   But even though that was “ancient history” by present standards, the code is still in service.

        Why, “the web page” has already become “like, so 2009...”
        So, if you're writing a webpage now, how are you preparing it for the 2013 needs?

        I don't know what 2013 is going to bring me, nor does my employer claim to know. Will there be another financial crisis? How will the oil price behave? How many more (natural) disasters/wars will there be? Will Google and Facebook still be dominant, does their balance shift, or will be there be more parties? And if they are still there, what will they do? Will we still be competing with the same players, do we have world domination by then, or will we lose marketshare because someone else has an even better idea than we do? Which other markets will be important to us in 2 years? We don't know, so we don't know what's needed in 2013. Heck, maybe the page I'm working on now isn't even liked by our customers, so it will be gone by 2013 anyway. So, does it make sense to spend time now so there may be some time savings in 2013? Hell no.

Re^4: Legacy Code: "Dominoes = Bad"
by Anonymous Monk on Apr 27, 2011 at 10:19 UTC
    But I take issue with blanket statements - just because it sometimes makes sense, doesn't mean it always make sense.

    Right, but how does your version of maintainable differ from your version of non-maintainable code?

    For me it doesn't differ much