Call me perverse, but I love the archaeological side of dealing with legacy software too. You start off with code that makes no sense at all, and gradually as you brush away soil from the pot shards, a story emerges. Working on porting Diablo to the PS1, there were tiny bits of inline assembler scattered everywhere. Eventually the light dawned: the original programmers had been struggling to understand C's signed/unsigned integer conversions so they fell back to the x86 instructions they were more familiar with.

    Working on porting Diablo to the PS1, there were tiny
    bits of inline assembler scattered everywhere.
    Eventually the light dawned: the original programmers
    had been struggling to understand C's signed/unsigned
    integer conversions so they fell back to the x86
    instructions they were more familiar with.

Dang, is that telling. Both shipped Diablo games have been know to be rife with security related bugs, and that kind of coding artifact gives a good indication of the quality of the programmers at Blizzard North it seems...

As my lead reminded me at the time when I made a snide comment about their quality: "We're sitting here porting it for peanuts, while they're busy counting their royalties"

Much as I prize technical quality, that lesson stuck with me.

Blizzard didn't pay out much in royalties in those days. Now Diablo 2 was a different matter...

There's legacy software... and then there are coding artifacts from another era. I'm not necessarily saying it's a deal breaker, but if your development tools consist solely of products that have been End of Lifed, you have right to be concerned how the job would affect your career development.

Legacy code isn't always bad. All code becomes legacy code.

Poor legacy code is a liability, and legacy code that leads to suboptimal technical situations (e.g. using C++ in 2009) is a pain.

What's wrong with using C++ in 2009?

It gives up all possible safety for performance gains that haven't mattered on the desktop for years. "volatile" is not enough of a memory model to write portable threaded code for I/O bound multicore machines. And it's missing an awful lot of modern conveniences that are painful or unreliable without language support: AOP, closures, currying, invariants, reflection, serialization, remoting, extensible syntax.

Echoing the commenter above, people writing C++ in 2009 are laughing all the way to the bank.

I don't know about laughing all the way to the bank, but I would probably have more difficulty writing machinery control code in anything other than C++

All legacy code is a liability, and all code is legacy.

To me "legacy" connotes flawed, not merely old. If a rewrite would end up slightly modernized but basically the same, what you have is an investment. If a rewrite would end up completely different because the old version doesn't meet the current requirements, what you have is a legacy problem.

You are distinguishing between "legacy" and "legacy problem" and thus rendering your own opening 'thesis as moot.

Sorry, what I was trying to get across is that I don't expect to hear "legacy" unless there's a problem.