Currently the best way I know to develop software is to grow it using TDD and Mocks*. Even if your team uses TDD and Mocks, there is a still a risk of you building legacy code.
The quickest and easiest way to build legacy code is to have a team of smart developers who write code that is smarter than the people that will inherit it.
Some organisations like banks have a standing army of “smart” developers. Other organisations do not have a standing army and need to bring in consultancies to build any strategic system. In doing so they may be building instant legacy applications as the consultancies will be building an application that is “smarter” than the developers who will be supporting it. The consultants may use thought processes and techniques that the team supporting the application are not familiar with.
This leads to the risk of legacy code that cannot be supported or changed. Parts of the application will become no-go zones that are coded around. Solid lumps of gristle in the application. Tests will break and go red but no one will care. All of this will lead to code that is hard to change, slow to change and subject to regression.
As you build an application, you need to build the team that will support it. Invest in the team as well as the software.
I’m sure others can share examples of how they do this.
* Check out Steve and Nat’s book on growing code guided by tests.