Legacy Code: "Dominoes = Bad"

[sundialsvc4]

In my peculiar line of work, I see a lot of legacy code.   In fact, I see a lot of bad legacy code, written (in most cases) by a “lone wolf” programmer who happened to be learning <Perl | PHP | Ruby | etc.> “by the seat of his pants, (making it up...) while going along.”   This painful experience has emphasized one thing:   “Dominoes = Bad.”

“Bad legacy code” is a chain of dominoes.   It’s a disaster waiting to happen.   The only reason why any of it works, is because the rest of it works.   Magic-value tests (e.g. $state eq 'I') are scattered willy-nilly all over the code base, with no particular rhyme or reason.   The application “works” only because (and therefore, only if) all of the planets are in perfect alignment at all times.   When any change needs to be made, anywhere in the code, the “ripple effects” can branch out ... not only across “space,” but also (quite literally) across “time.”   You might find yourself trying to wrap your head around observations like these, upon which the existing code utterly depends:

$state shifts from 'I' to 'S' only after the user does ..whatever.. after doing whatever-else..., therefore the code that I am looking at right here tests for 'S' ...

“Good code,” whether it is “legacy” or not, contains no temporal assumptions.   Or other assumptions, for that matter.   Instead, the code that you are looking at is “a statement of present fact,” with no prerequisites or co-requisites.   It stands alone.   And, if something is nonsensical about whatever it sees, it is the one to raise the alarm.

“Good code,” “bad code,” it’s all really a matter of maintainability.   Good code consists of carefully placed, well-defined and well-defended “islands” of functionality with a minimum set of interdependency upon “everything else.”   Bad code is precisely the opposite.   The only way to understand “bad code” is to understand everything at once.   Which is a lost cause.

Opinion yours?

[danb]

Good post, sundialsvc4. I would characterize what your saying as granularity, modularity, and/or atomicity. Code is easier to understand when it is small (e.g. functions of 80 lines or less) and does not require knowledge of other parts of the system to understanding.

That said, while such granuarlity/modularity is important, it's only one factor in the list of things that I could consider in evaluating the goodness of code. There's also style, simplicity, artistry, suitability of the algorithm, etc.

Also, I would argue that "contains no assumptions" should be "contains no *unstated* assumptions".

[maio]

I can feel your pain. :) For last few years we have been fighting/taming big legacy system written in Perl with a lot of chain of dominoes that you are talking about. But I have to say it's been great learning experience for me.

At the beginning, it took us months to deliver fixes/new functionality and each release was followed by days of fixing things that we broke by that release. Than we had this 'great' idea to do complete rewrites instead. It took us one and half year and resulted in completely new legacy code. There are several articles on web why rewrites are bad idea and now I totally agree with them. http://www.joelonsoftware.com/articles/fog0000000069.html

Fortunately we finally did find way to do it better and now we are able to make big changes across whole system in just few days. A lot of things that made it possible are summarized in Michael Feather's book Working Effectively with Legacy Code.

Because of this legacy experience I now really-really appreciate code that is as simple as possible and is fully covered by tests.

[raybies]

Unfortunately many of the longterm safe/quality practices don't always matter to those initially in charge of a project, and so you'll find a group that develops and then goes on to do something else that's never been done before--without thought to how they might've made it last forever and ever.

The mindset is often that there will always be something newer and better, and why maintain something when you can always rewrite what doesn't work later?

In some ways it's a matter of "We'll cross that bridge when we come to it." Also designers often take an anything goes attitude because they tend to get paid a lot, while code maintainers (the IT grunts) get paid a lot less to keep it working. I would expect that some developers probably have nary a thought of them or their feelings, they're paid to prove concepts.

When i worked with coders in the game industry, one of the most difficult motivational tasks for me as a project manager was getting the expert coders to do the boring coding... the stuff like tweaking the AI, fixing typos, and organizing code in a production release. All that takes a lot of discipline that was not appealing to the hot-blooded trailblazers of the coding universe.

It isn't always so, however. I know some folks who are proud their code is still being used after a decade. Though they're often the first to claim it's not good code.

finally there's an aspect of budgeting for maintainability that's hard for a lot of folks to swallow. It's the idea that if it's an expense in the future, that it's an expense at all. If I'm a manager and have a forty million dollar budget, thirty of which is for maintaining the project over the lifetime of the project, what are the chances I won't be tempted to spend that now? Or that my upper management won't cut that eventually anyway, because it's a huge expense that's just hanging out there unspent... future expenses are liabilities that make accountants nervous. Heck, accountants don't like it when you save up too much vacation time...

Of course those are external factors to what really should be self evident. I do wonder what some would consider "maintainable Perl" because I've heard a lot of folks claim that Perl isn't maintainable (mostly because they don't know it... which maybe is part of the problem with Perl... you have to hire a Perl expert in order to maintain it... and that's another expense that may not be worth the effort economically speaking, when Java coders are a dime a dozen in some country where wages are even less than that...)

--Ray

[sundialsvc4]

I would quite frankly say that my chosen market-niche as of late consists of finding the “cast-off” code ... that (former) developers are quick to have a “Mission::Impossible™ attitude” toward ... (“the State Department will disavow all knowledge of your actions”) ... but that is very much still in service ... and staging an effective turn-around for that project.

“Life’s been good ... to me ... so far ...”

It would, indeed, be a wonderful thing if a software project ever actually reached the point:   GAME OVER.   “Congratulations, Mr. Phelps.   You won the game.   And the game, having now been won, will most assuredly never change.”   In my experience, “the game” is not like that ... and I, for one, am very glad indeed that it is not.   Because, if it were, I would not have a career.   Life goes on.   Business does not stop.   Everything that you accomplished last year, doesn’t mean one frippin’ thing this year.

---

And as for the “cheap (sic...) Java coders” .... well ... just because your accountant proclaims that something is “cheaper,” does not actually establish that it actually is.   (And if you don’t believe me on this, just ask your accountant what he or she thinks about “a ’cheaper’ accountant.”)

[JavaFan]

Everything that you accomplished last year, doesn’t mean one frippin’ thing this year.

Too bad for you. A lot of what I've accomplished last year is still generating revenue for my employer this year.

[raybies]

Buwahahahaha! I'm definitely using that "cheaper accountant" thing... Great thoughts, --Ray