Keith Elder’s recent post Dear Asp.Net Developers: Stop Making Our Technology Look Bad had a lot of great points but towards the end, I thought he suddenly swerved off the road. In general, I agree with Keith that developers have a responsibility to provide all of their users with a good experience. This is not always easy and I give sites lots of slack when I see they made a reasonable effort. But when I see sites like the CodeZone example in Keith’s post, I have to wonder why those developers still have a job or where were the senior developers on the project.
Where I vehemently disagree with Keith is that his “solution” is for Asp.Net developers to adopt the MVC framework and NVelocity (or other non-webforms or non-Microsoft tools). To me this is a complete non-sequitur. You can create perfectly useable, XHTML/CSS compliant websites using WebForms and Visual Studio. It is not hard. It is just a matter of caring. Hundreds of thousands of developers do it every day. Lazy, uncaring developers will still be lazy and uncaring even if they are using the MVC framework.
But Keith Elder is not the first or the only developer to fall into this trap. You can see frequent posts like Convenience Kills, or the Case Against RAD Tools from Nate Kohari, or the recent set of twitter comments from Alan Stevens. These represent just a small tip of the iceberg in the development community. If you spend any time in blogs, forums, twitter, etc. you will invariably see a thread of thought that says that some tool, language, design pattern, or component is just wrong and should never be used. Rarely is that the case. Usually it is just another “language war” in a different suit.
The problem with each of these arguments, from Keith, Nate, Alan and others is that it takes the developer out of the equation. It places the blame for bad software on the shoulders of the tool or the framework – i.e. Drag and Drop is bad because it leads to unmaintainable code, or WebForms is bad because it leads to non-compliant web-pages. I am responsible for every website I create. If I create a site or application that is unmaintainable or that has poorly formed HTML or doesn’t render well in all browsers, that is my fault. I chose my development tools/framework, or my employer, who I choose to work for, chose the development tools/framework. Either way, it is my responsibility, as a professional, to do my utmost to create the best possible application that is within my capability to create.
If I see a sample application, as a professional developer, I have to acknowledge that it is not intended to be production code. Samples and demos are intended to show off a certain feature, not teach you good programming techniques. Not only do I have a responsibility to do my best, I have a responsibility to help guide and train junior developers how to apply best practices to solve problems. Sometimes this will mean explaining to them why a particular control or coding practice is rarely a good choice, which is different from saying that it should never be used. Some person standing in front of a room of hundreds of developers, with only 60 minutes at their disposal, will rarely have time to dive into the details to explain the various nuances for a particular, tool, framework or control, or to even to explain why they may or may not be appropriate in a certain situation.
I like to look at software development much like my woodworking. In my shop, I have collected hundreds of tools. Some of them general purpose tools, and some of them have very specific uses. I have a mix of hand-tools and power-tools and I am adding to my collection all the time. For every project I take on, I try to choose the right tool for the job, where the right tool is somewhat constrained by the tools I have available and that I know how to use. In the end though, I know that for any given task that I have several choices for which tool to use. I also know that in the hands of a master craftsman, almost any tool can be used to achieve stunning results. In woodworking, we don’t blame our tools for our own lack of skill or the poor quality of our work.
I wish that Keith would have pushed developers to learn how to properly use their chosen framework/language/tool, rather than promoting one more tool, as if MVC will be the panacea for the cross browser issues he despises. I wish that Nate and Alan had focused on the specific issues with Drag and Drop and how Microsoft could improve the components and frameworks to be less black box and more maintainable. I wish the developer community in general was more tolerant of the preferences of other developers rather than always thinking that our way is the “one true God” and that anyone who uses a different tool/framework/language is an infidel who must be converted to the cause – often at knife-point.