Sunday, January 9, 2011

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.


  1. Excellent post. I've only been a .NET web developer for a few years, but I pretty much abandoned WebForms as soon as MVC was an option. I found it almost instantly liberating to embrace HTML+CSS+JS as a method of building the UI, though I also understand it is challenging at times too.

    Lately, I've been work on building RESTful APIs in .NET for Azure based services. However, having spent a small amount of time (a faction of my .NET experience) hacking around with Rails+Heroku and Node+Joyent, it has started to dawn on me .NET may simply not be the right tool for web development.

    Microsoft is really just playing catchup with other frameworks these days. Innovation in the .NET web stack is almost non-existant and the lack of guidance on best practices, conventions and tooling in the .NET world really makes it more painful than the alternatives.

  2. I'd love to get some more Ruby and Node experience under my belt. I haven't had time lately, but hopefully that'll change. The reality for me these days is that if it's not relevant to what I'm doing at work, it has to be on the back burner.

    I wouldn't say that .NET isn't the right tool, one just needs to make sure to approach anything .NET objectively. The same goes for any tool, really. There are various factions of the .NET community, and I'm liking the Mono side of things more and more than the Microsoft side of things. Some of the things Microsoft releases are just awful, or are useful only if one is doing _everything_ the Microsoft way, not a la carte.

    I think Microsoft was really onto something with dynamic language support, but then they dropped it. I really hope the community picks it up and runs with it. If I could use Ruby and/or Python natively in Visual Studio without any trouble, I'd be very happy. But if I have to ditch Visual Studio and go with Mono alternatives in order to stay innovative as a developer, then so be it. The challenge won't be in switching, it'll be in making it work at my employer.

  3. I honestly think Mono will be the place to be. That is if you are wanting to do .net development. The fact that I could do true multi-platform development including Android and iOS is awesome.

    I do hope the DLR takes off the .net world needs to realize that these are serious options and have it be a part of the platform.

    Also I feel a bit honored to have inspired you. I certainly respect your ingenuity and intelligence. I hope one day we can work again on a project.

  4. I really haven't been keeping up with the new stuff in Mono. One of my bigger concerns with Mono has been the need for mod-mono and apache. Has this changed or improved more recently.

    I absolutely agree with the need to see more dynamic language power in .NET but arguably they do have the IRON stuff (check out the IR 1.1 release, much better VS integration support). That said, if I was going to use Ruby or Python I'm not really sure what I would need .NET for. I will say having really tried hard to play around with dynamic and ExpandoObject I am less than impressed with what it does (which is essentially nothing).

  5. Admittedly, I haven't kept up recently either. I was really into Mono a very long time ago, back when they were just working on meeting .NET 2.0, but have only vaguely followed it since. I know what they've been up to in terms of blog posts and such, but haven't used it in a while. I'd like to change that in the near future.

    You do have a good point about asking what being on .NET gives you when using Ruby or Python. I guess from my perspective it's a matter of the corporate culture. If it works well in Visual Studio, it's easier to get the team at work on board. I guess I can think of IronRuby and IronPython as gateways to Ruby and Python in a well-entrenched Microsoft environment.

  6. Yeah the use of the Iron* languages is that you can take advantage of any investment already in .NET. So favorite libraries, pre-existing code, dropping down a level for performance means C# not C (plus a lot of marshaling code). Or the more strictly defined sections of your code in C# and the looser stuff in Python. Easy example I see is your UI code versus Domain Model code.

    I wouldn't say the point of it is so you can call Python code from C#, but being able to go both ways cleanly is great I think for proper integration in the platform. Also I have seen code for casting a dynamic object to an interface (it generates a proxy) to help bridge that gap better. Good for making migration paths easier to find.

    I will also say that I think it's a sad note that in the .NET world (this probably exists in the Java world as well), if you don't have Visual Studio integration then it's not taken seriously. I personally see VS has something forced upon me because it's MS and handles THEIR project files cleanly for THEIR build tools. In C# you do need an easy way to keep up with files for compiling, but in a Python or Ruby project this isn't needed. I actually prefer my VIM and .

    Now I do like some things about Visual Studio. It's a pretty fine IDE (especially with ReSharper)... well 2010 is annoying, anyway. I would just rather work with a different environment.

  7. Google doesn't really embrace JavaScript. They just wrap them in Java because most of them don't know JavaScript either. LOLOLOLOL...

    /just trolling the truth