In my previous entry about Morts, Nick Malik left an interesting response. What caught my eye the most was his comment that:
"If you find yourself having to maintain a program that was not written to be maintained, don't blame the maker of the tools!"
I agree with this sentiment to a large degree. How people use the tools, is critical. But, that's only part of the story. See, a lot of tools don't lend themselves towards wiring maintainable code. Some of Microsoft's current tools fall in that category, unfortunately. For example, some don't lend themselves towards creating testable code. That's a big problem all by itself.
So I'd like to take Nick's comment and turn it an opportunity. Sure, it's the people using the tool that take most of the blame, however, the maker of the tool may (should!) have a significant responsibility in creating tools that encourage the creation of maintainable code. (Notice I use the word encourage here).
There's a thin, but significant line between tools that allow you to create crappy code quickly and then leave you high and dry, versus tools that encourage you towards creating good code. The key here is that the tools should make it as painless and natural as possible to do the right thing. This is not about wizards. It's not about visual designers. It's about code.
Microsoft is in a unique position to provide this, but so far some teams within it insist on making the default way of creating applications to be the one that favors quick and dirty over the one that favors maintainable code. The latter does not need to take longer, be more complicated, or be harder than the former, but some tools insist on making it that way. Choosing the right abstractions, by the way, is a key step here.
