My favorite definition of a "legacy system" is "a system without automated unit tests". After spending my entire working life (nearly 25 years) in software development, and having worked for over 3 years in the IT division of a huge organization on one-million-line projects that have virtually no automated unit tests, I can confidently say with no doubts that automated unit tests are an absolute, total, unqualified, 100% must-have for the medium- to long-term viability of a large project. There are many reasons for this, but the most important one is this: I have seen many developers in this organization almost tremble in fear at the thought of having to make a change to production code, lest it result in an expensive and high-profile production outage. The lack of unit tests to catch functional regression is so fearsome that teams have written totally new systems rather than try to work with existing ones. Of course, said teams write legacy code right from the start because they *still* don't create unit tests, so their successors will throw away their code, too.
I cannot even begin to estimate the massive waste of resources, the frustration, the stress, the long hours - all totally unnecessary - as a result of not having automated, properly designed and executed unit tests. I'm not going to go into what constitutes a proper unit test - there's not enough time for that and there are plenty of resources out there.
What many people don't realize is that the mere fact of having thorough unit test coverage ensures that you have testable code. Testable code is *in general* better designed and more flexible than the alternative. It *has* to be by the very nature of testability, which requires a great degree of decoupling and reusability (namely, the code needs to be "reused" by the test cases).
In addition, unit tests help to answer many questions about what the code is supposed to do. The reality of many large IT divisions is that there is never adequate documentation, and there are literally millions of lines of code that people simply don't understand and are afraid to touch. A decent unit test suite would go very far towards compensating for the lack of other information about what all that code does.
However, from what I have seen, the likelihood that the corporate IT developer will create anything approaching good (or any!) unit tests approaches zero. Sorry to be negative, but I have just seen too much (or, perhaps I should say, too little). Quite frankly, I have come to believe in Sturgeon's Law, which I will paraphrase: 90% of software is crap, because 90% of everything is crap. Have a great day.

About agile methodologies: there's a lot to like about them, but they are again no panacea. There are many situations where you would not dream of using them (like writing space shuttle software). Alistair Cockburn has a matrix that determines how heavyweight a process is needed, based on the team size and the size of potential loss due to system failure (e.g. loss of time, loss of money, loss of life). I propose that there is another factor that needs to be considered: volatility of interfaces.
When you are architecting a large system that presents many interfaces, especially external interfaces, you can't blithely say that if you don't need it right now, you'll put it in sometime in the future. Quite frankly, as with writing software libraries, if you don't get your interfaces right by the time you release the software, you are S.O.L. because the interfaces are now cast in concrete. Once you have a large user base out there you can't just decide to refactor and rearchitect because you didn't get it right before releasing it. You will face a revolution in your user base, unless your user base is so captive that all they can do is grumble and shake a fist at you. A case in point: Microsoft changed the Windows API many times in the early days, and it cost the world a huge amount of grief. Not that MS Agilists; far from it. At the time, they were little more than cowboy coders, but the principle holds.
I am not saying that Agile methodologies are bad - on the contrary. In many cases they are just what you need. Just use them when applicable.
One poster said that you must have detailed and well-written requirements documents. Well, I have news for you. In many of the jobs I have had, that was just not possible because (a) very, very few people can write a really good requirements document (b) the end users/stakeholders often don't know what they want up front, and they often don't even know what they know, so it takes a highly skilled analyst to get the details out of them (c) there is such a lot of pressure to get a project going that not enough time is given to do this, and (d) the information superhighways are littered with the corpses of projects that tried to use a waterfall methodology, which is what I think of when I read about having complete requirements up front.
I mean, yeah, I'd love to have great requirements docuemnted up front, but in reality? I have seldom seen it happen. If you get anything, it's a stack of documents that are so inconsistent, and missing so much necessary detail, that you wind up interviewing the users yourselves, and doing an evolutionary delivery of the system. By all means, if you have a crackerjack business analysis team that can nail 99% of the requirements, that's great. Many of the rest of us don't.
So, as people like Steve McConnell recommend, adopt the development practice that is most suitable for your particular project. If that's an Agile, low-ceremony practice, great; if it's a heavyweight, high-ceremony process, well, that's what is needed. The only general certainty I have is that of the systems I have worked on in the past 20 years, only those that were developed using a model based on iterative development and incremental integration were truly successful. Some had comprehensive upfront requirements; most didn't.