Lately I've been on something of a crusade on "using the right tool for the job." It's becoming sort of my mantra for software craftsmanship. The idea is that the tool is less important than the craftsman. It's more important for a developer to perform a job well and produce a well-crafted product than it is for a developer to produce a product that fits within some contrived notion of what that developer should be doing. I often sum up this idea by saying, "It's better to be a developer who knows .NET than to be a .NET developer."
Now as you may already know, I am a web developer by trade. I specifically develop enterprise web applications on the .NET platform. I've been doing it for a while now, and I like to think I'm pretty good at it. You may also know that I look back on web forms with a kind of shame. Sean, you know what I'm talking about. It got the job done, sure. But was it the right tool for the job? Was it the right approach?
Davy touched on this a good bit in his post. The age of web forms is by no means over (at least not in the more stuffy and slow-to-progress corporate environments). But the ASP .NET community has poked its head above the water enough now to at least look around and see what else has been going on, and to get a more high-level view of web forms and what it really was. It was the wrong abstraction. (It looked like a duck, quacked like a duck, but needed batteries.)
Web forms represented a fight against the "web way of doing things" and an attempt to push that under enough code (using the dreaded "pluggable widget model," my arch nemesis in software craftsmanship) that developers wouldn't need to worry about all that web stuff and could just focus on good old rapid application development. And, as Davy pointed out, what did this lead to? Too many post-backs, slow load times, poor web software in general. It was a web platform that actively fought against the nature of the web, attempting to obscure and deny the very foundation of what it was doing.
Now, in the past year I've held four different jobs. Career-wise, it's been an interesting ride. But it's given me an opportunity to work with a lot of different people in various corporate cultures and learn a lot about how corporate developers can think and work. And I hate to say it, but a lot of times the focus is incorrectly placed on the tool rather than on the craftsman. And the tool in question at the moment is ASP .NET.
There's an old saying, "Nobody ever got fired for buying Microsoft." And since Microsoft is in the business of building and selling tools, this kind of mentality has led to too much focus on the tools and not enough on the craftsmen. No, I don't have any Microsoft certifications. No, I'm not a Microsoft MVP. I'm not interested in those things. I see no value in them. (If you do see value in them, then by all means go ahead and use them. Value is relative, it's all in the perception. So don't think that I'm somehow de-valuing your own expertise for the sake of my own, because I'm not.)
The point that I'm getting at is that I've seen a good number of developers who cling to ASP .NET as a kind of catch-all tool that can be used to address all of the requirements they face. And, even worse, they maintain a very narrow view of what ASP .NET can do for them. If it's in an MSDN tutorial somewhere, or on a ScottGu blog post somewhere, then it must be right because it's the Microsoft way of doing things. It's safe. It's the tool we use, and we must obey the tool.
In my travels this past year (not just at work, but also in helping people on Stack Overflow), I've heard such interesting (and frightening) statements made by web developers as (paraphrased):
- "Why should I use CSS? I can just set the properties on the controls."
- "What do you mean there are too many post-backs? How else is it going to use the code?" ("The code" in this case was simple string manipulation in the UI, nothing more.)
- "Why didn't you convert this HTML to .NET? Isn't the site written in .NET?"
- "We can't use Rake, everything we do has to be done from within Visual Studio."
Well, just take a look at Google's products and how they're crafted. They don't do anything "the Microsoft way" or "the Sun way" or "the Oracle way" or any other way. They do things "the Google way" and, by that, they do everything they can to use the right tool for the job and use it well. Rather than pick a tool and try to fit all of their requirements into the skill set of that tool, they use whatever tools are at their disposal. They even make their own, if the need arises. In developing on the web as a platform, they have demonstrated beautifully the importance of this. They have embraced the tools of the web.
Look at Google Maps as an example. Let's say your company wanted to build something like that. Could you build it in ASP .NET with Microsoft's pluggable widgets? (Well, you'd use some Bing stuff instead of some Google stuff, but you get the idea.) Sure. Would it be as sleek and polished and well-received as Google Maps? Not a chance. Your ASP .NET map site, though it uses the approved and well-established tool(s) you love, wouldn't be using web technologies properly in this particular case. All the functionality may be there, but the user experience would be kludgy at best.
Davy's last paragraph was short and simple, and just a touch of inspirational:
The web as a platform (I still don't like that term for some reason. I need to figure out why.) is rich, engaging and strong. And web development is, at least for me, interesting and fun. So stop hiding behind your tools. Stop clinging to the software development model that Microsoft has tried to force upon you. Keep in mind the market forces behind a lot of Microsoft's decisions. When ASP .NET first came out, Microsoft was pitiful for web development. They designed it in part to allow VB6 and COM developers to be able to jump on the web bandwagon. Don't get me wrong, ASP .NET has come a long way and I love a lot of what the community has produced. But the old cruft is still there. Scrape off that cruft, and embrace web development.
P.S. I would like to point out that some of the people I've worked with in the past year are not the ones I'm talking about/to in this post. For the most part, you all know who you are. Some of you have in fact been a point of much inspiration for my work. Sean and John are the most relevant examples of this.