The Right Tool For The Job

I just finished reading Davy Brion's latest blog post, entitled "Learning To Work With The Web, Instead Of Against It."  It's one thing to say that I agree with his point, which I wholeheartedly do, but it's another entirely to continue the point and take it in hopefully a relevant, albeit tangential, direction.

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.

Unfortunately, this has led to a whole industry of "web developers" who know little if anything about HTML, CSS and JavaScript.  These are the core components of web development today.  Everything you present to the user in ASP .NET gets translated into these technologies.  But the tool does everything it can to hide that fact from the developers, and thus the developers remain blissfully unaware of it.

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):

• "I don't know JavaScript, so I can't support that.  Write it in .NET instead."
• "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."
• etc.

On another note, I've also heard my fair share of non-developers, the business users in an organization (managers, sales and marketing, executives, etc.) make some interesting comments.  And my favorite one for this discussion is simply, "If these other companies, like Google, can make such great web applications, why can't we?"  (Well, first of all, Google pays for top developers and treats them with respect and admiration.  Google's bread and butter is web development, so as a business it does everything it can to foster the capabilities of its developers.  Many of you, on the other hand, see your developers as servants who must be kept in their place.  But I digress.)

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.

Google employs a lot of JavaScript in a product like that.  Plain old JavaScript.  That same language you used twelve years ago to make text-box-based tic-tac-toe games in your browser, or to make little swinging tails that follow the cursor, or to make a scrolling marquee in the browser's status bar.  But they didn't just use it, they embraced it.  They didn't just write code that happened to be in JavaScript, they embraced a fundamental understanding of what web development is and how it works and where JavaScript fits into that.

For every ASP .NET developer I've seen avoid JavaScript, I've also seen one who "uses" it, by which I mean they copy/paste somebody else's JavaScript code onto their page in order to accomplish something.  You know what that is?  It's a pluggable widget.  It's a block of code that the developer didn't write, and more importantly doesn't understand, but somebody said it'll work and it seems to get the job done so they go ahead and use it.  (I'll admit it, I've done this many times in the past.  But no more.)  Sure, it's JavaScript, but it's not the tool that matters.  It's how you're using it.  You're using that JavaScript like any other ASP .NET web forms control.  You drag it onto the page and forget about it.  You don't know (or even care) how it actually works and what it actually does.  In other words, you're still denying the very nature of web development while you are engaged in web development.

How do you think Google's products would work if they did that same thing?  It would be a mess.  So, to answer those business users who want to know why their development teams can't do this, it's because their development aren't embracing web development properly.  They're trying to fit the web into their toolbox, rather than expanding their toolbox to embrace the web.  You can't change how the web works.  Honestly.  New things come along, sure.  But you're still talking about HTML, CSS and JavaScript on the client side and some back-end technology on the server.  You're still talking about a stateless request/response model.  There are abstractions to this, some more successful or useful than others, but you have to embrace the fundamentals of the platform itself.  You can't abstract yourself away from the very foundation of what it is you're doing.

Davy's last paragraph was short and simple, and just a touch of inspirational:

I don’t know what you will do, but i know what i’m going to do. I’m going to learn how to work with the web instead of against it. I’m finally going learn HTML. I’m going to learn CSS. I’m going to learn JavaScript. I’m going to learn about REST. And i’m going to be using that knowledge years from now as i follow the further evolution of the web.

I wish more developers would espouse that kind of attitude.  Replace "I don't know JavaScript so I can't support that" with "I should learn JavaScript so I can better support, or even better create, web applications."  I'm still learning too, Davy.  My HTML is pretty strong, my JavaScript is getting better all the time, my CSS is limited by my poor graphical layout and design skills.  (I'm one of those people who just tinkers with the CSS unit it works, rather than actually writes it from the start with a real plan and a real understanding of the tool.  At least for now.)

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.