All that, and I’ve still enjoyed working with MVC more than Monorail so who knows, right? Monorail is certainly a more complete and mature framework at this point.

If I was just starting out, using ASP.NET webforms, I’d take all of that code that ends up in your code-behind files and figure out how to move it into other more “service oriented” classes. The less code in the codebehind, the better. And now that I have it out of the webform, I’d start figuring out how to make it testable – decoupling from the data access for example, and using more descriptive objects instead of working with WebForm controls (don’t pass a TextBox reference around, do something meaningful with the Text instead…)

Tools that I like: TestDriven.NET to make running tests easier, either Spring.NET or Windsor for doing dependency injection, NUnit as a straightforward test framework, and RhinoMocks for when you get into the need for auto-mocking objects.

And I love this: “If you look at last year’s code and think that you’d change absolutely nothing, doesn’t that at least imply you haven’t improved your skills?” If that’s not an argument for continuous learning, then I don’t know what is.

I’ve been puzzled by why this is so challenging for some developers. Is the problem that they run out of time in the schedule? They don’t estimate for it prior to starting? They don’t know how to do it well? They don’t like to do it because it is not as enjoying as coding new functionality? They don’t understand the benefits? I suspect it’s all of the above at some level depending on the individual.

Then the question becomes, “How to we instill these best practices in more programmers?”

To that end, non-technical stakeholders may not need to know about unit testing any more than they would know the details of design patterns. If you can fold unit testing into your usual way (and cost) of doing business, then you just have to get all the developers on board. Hopefully they quickly see the benefit after years of doing it “the hard way”