Jdn is making an excellent point in this post:
Okay, so, TDD-like design, ORM solution, using MVP. Oh, and talk to the users, preferably before you being coding.
One problem (well, it's really more than one). I know for a fact that I am going to be handing this application off to other people. I will not be maintaining it. I know the people who I will be handing it off to, so I know their skill sets, I know generally how they like to code.
None of them have ever used ORM.
None of them do unit testing. One knows what they are and for whatever reason hates them. The others just don't know.
None of them have ever used MVP/MVC, and I doubt any but one has even heard of it.
All of them are intelligent, so could grasp all the concepts readily, and become proficient with them over time. If they are given time by their bosses, or do the work overtime, or whatever.
There is a 'standard' architecture in place that they have worked with for quite some time. I personally think it blows, and frankly, so do most of them, but it is familiar, and applications can be passed between developers as they use a common style.
There are several things that are going on in this situation. The two most important ones are that the currently used practice of bad code, is also (luckily) wildly recognized as such and the people who work there are open minded and intelligent.
Before I get to the main point, I want to relate something about my current project. If you wish to maintain it, you need to have a good understanding of OR/M, IoC and MVC. Without those, you can't really do much with the application. That said, good use of IoC means that it is mostly transparent, and abusing the language give you natural syntax like FindAll( Where.User.Name == "Ayende") for the (simple) OR/M, and MVC isn't hard to learn.
Back to Jdn's post, let us consider his point for a moment. Building the application using TDD, IoC, OR/M, etc would create a maintainable application, but it wouldn't be maintainable by someone who doesn't know all that. Building an application application using proven bad practices will ensure that anyone can hack at it, but that it has much higher cost to maintain and extend.
I am okay with that. Because my view is that having the developers learn a better way to build software is much less costly than continuing to produce software that is hard to maintain. In simple terms, if you need to invest a week in your developers, you will get your investment several times over when they produce better code, easier to maintain and extend and with fewer bugs.
Doing it the old way seams defeatist to me (although, in Jdn's case, he seems to be leaving his current employee, which is something that I am ignoring in this analysis). It is the old "we have always done it this way" approach. Sure, you can use a mule to plow a field, it works. But a tractor would do much better job, even though it require knowing how to drive first.