Making good programmers feel like bad programmers

A web developer friend of mine has been doing a lot of backend-integration-type work over the last year, and has therefore has not been developing web sites. He made a point of wading back in to the web this week, so as not to get too “rusty”, in his words.

He is working in Web Forms – and the wading did not go well. He is struggling to do what he considers basic stuff like toggling between an edit form and a detail view.

Now, he’s been doing web work since the mid-90’s, when the tools were extremely raw. He knows web apps. And right now he feels like an idiot.

Is he as rusty as he says? No. The problem is the abstraction layer that is Web Forms. It was designed for people who don’t know how the web works; it abstracts away all the request-response stuff in an attempt to achieve a desktop-app metaphor.

Sadly, for all its sophistication, it can feel like doing surgery while wearing boxing gloves.

If you do know how the web works, you may find this abstraction hurts more than it helps. Knowing “when” a piece of code will execute under Web Forms, or what an element’s value will be at the time, is mysterious. It wants you to commit completely to its event-driven metaphor – in other words, to forget what you know about the actual web.

If your project requires you to jump outside the metaphor, then you end up in a special circle of hell, one where some things happen as you expect them to, and others don’t. It is a classic leaky abstraction.

I say this as someone who has spent a lot of time in the web forms page life-cycle. It is quite an achievement in many ways; it opened the web to many traditional desktop developers. However, in 2009, it feels like a lot of useless beauty.

The result of such high-level abstractions is that a good programmer (like my friend) feels like a bad programmer. I suspect I’ll find him going back to basics soon.

14 thoughts on “Making good programmers feel like bad programmers

  1. Bravo. Well put, Matt. Great metaphor too.

    However, I would have to disagree that you have to forget how the web works to use WebForms though. While it certainly does persuade developers with a siren’s call to believe the web has state and concepts like JavaScript, HTML, and the DOM are just output; it certainly doesn’t require that.

    For every time I read an article that discusses the drawbacks of the web form model raising a generation of developers who only know “postbacks”, I think about all of the web developers I still know who have never compiled a line of code, considered variable costs in terms of memory allocation, or have a firm grasp on how their server platform ultimately operates.

    So, who really lives in an abstracted layer?

    I do emphatically agree though about the MVC back to basics though. It’s certainly more in tune with what web development once was. The few POC projects I’ve done with it have been a total joy. But, I think those of us who developed on the web form platform the past few years are better programmers for it.

  2. The problem is your friend is using Point him in the direction of Rails and I’m sure he will be a lot more happy and feel like a great programmer once again.

  3. Hi, I just couldn’t stand your link to the metric system. For a young european, or anyone else in the world but (North) America, the metric system is not only beautiful, it’s extremely useful. An engineer that doesn’t consider it useful sounds bad because this means he had not ever think about(worked with anyone) the rest of the world. The american engineers(in science) I know use and love the metric system.

    No, we don’t think in decameters. But we thing on kilo-Mega-Giga-Femto grams/meters and deci-centi-mili-micro-nano grams/meters. Cubic and square meters,liters(dm^3) and so. It makes live easier and more productive than pounds-inches-slugs-feet-gallon-btu.

    Americans don’t want to change for the same reason Chinese people consider important their children to learn 5000 symbols(13 years old could read with latin alphabets, with chinese you can’t read a lot of things at this age, it takes hundreds of times more to do the same!!). The reason is adult people had already learnt their system, so they don’t want to learn another system.

    And we were the first to use miles(the romans were using them), inches, feets and gallons. In fact, there was a time in witch every country had its "feet", or "inch". It is an outdated system.

  4. Jose, I agree! The metric system is perfectly efficient. (My education is in science.) Nice analogy with the Chinese alphabet.

    I just think that perhaps regular "users" don’t see an obvious benefit in their daily lives. Habits are hard to break, so people need to see a real-life reward.

    The Roman alphabet is arbitrary, and so are seconds/minutes/hours. We are satisfied with those, for some reason.

  5. I know exactly how he feels, whenever I have anything to do with .Net it is the same. They have added all this stuff to make it "simpler", which hides what actually goes on underneath. I know what goes on underneath, and understand it well. There methods just confuse me slightly, until I get around to that way of thinking again.

    Part of the idea is to get programmers who are no good at anything else but .net. They can’t stop thinking that way…

  6. I have to also recommend ASP.NET MVC. For years, I’ve been dissatisfied with the way WebForms goes against the REST model. One particular irritation is that it co-opts the id attribute, which gets in the way of taking full advantage of JavaScript and CSS. On the other hand, the .NET platform is excellent. With the introduction of MVC, we have the best of both worlds. Check it out.

  7. ASP.NET is an extremely fractured system, no doubt. I’m studying for my ASP.NET certification and the system is extremely hard to grasp because it is, in fact, tens of little systems all put together incoherently. And it gets worse as you add AJAX in. The purpose of WebForms is to simulate state over HTTP; the purpose of AJAX is to keep state in the browser. The two conflict, and right now they do not play well together.

    I’ve not really looked at MVC yet, but while I think the .Net framework and C# is an excellent foundation, ASP.NET Webforms is a layer which doesn’t hold together conceptually.

  8. I agree with Trevor.

    For every occurrence of a specific example, I have been able to show how to achieve the result in ASP.NET.

    The problem with your friend, and for everyone else who dislikes ASP.NET, is that they want it to work in a way it was never intended to work. I wrote about this here

    The problem with ASP.NET, if you can call it a problem, is it is the right model at the wrong time.

    In short, ASP.NET expects you to understand Event Driven, Object Oriented programming. Once you understand that, it is no more difficult to program an ASP.NET application than it is to program a Windows Forms application.

  9. Thanks for that comment Dave. There has been a huge amount of hate directed against webforms when in reality people don’t really understand event-driven and object oriented programming very clearly it seems. There is an event for *everything* that happens in the page life-cycle, all that needs to happen after that is you override the event to do whatever needs to be done based on your project. mvc just adds tons of unneeded complexity in most cases imo. If all you have is a simple CRUD page with low traffic then go ahead and knock it out with a simple webform project and be done with it. Otherwise, if you have a larger project that needs more flexibility and scale it might make more sense to go with a mvc project instead it really depends on the context.

  10. Heheh, the seconds/minutes/hours is not arbitrary, it was a finger counting system invented by summerians (or other people in that are, I don’t remember exactly). It is quite useful as 60 it has a lot of divisors (2, 3, 4, 5 and so on) and hence simplified many computing operations for them. Of course it is outdated but it still allows for a certain ease of use with time computations (we have 5 minutes, 10 minutes, quarters, half hours, all divisors of 60 :) ).

  11. The test of any web framework or programming paradigm should be the question, "Would you want to program that way when building desktop applications?" I mean, it’s easy enough to create a tiny web server that accepts calls only from and starts a browser to the page it publishes, so theoretically you could use the web paradigm for [b][i]everything[/i][/b]. But execution efficiency aside, would you? Of course not! That just proves the primitive inadequacy of our web tool kits.

    The problem is that the web is based on HTML, and HTML is neither object-oriented nor event-oriented. This causes an impedance mismatch as severe as the impedance mismatch between OO programming and the RDBMS. (This trouble alone, the impedance mismatch between Java and SQL motivated the development of Hibernate.)

    Given the failure of the OO database idea, the impedance mismatch between programming language and database is inevitable; not so with the impedance mismatch between the server and browser technology. After all, there’s no law saying that thin clients [b][i]must[/i][/b] be coded in HTML. And if web browsers impose that on us, then our tools can and should abstract the HTML away from us.

    The problem with ASP.NET WebForms is not that it abstracts away the HTML, it’s that the abstraction just isn’t good enough. Yes, it’s a leaky abstraction. It reminds me of COBOL’s attempt to abstract away assembly language.

    The abstraction provided by COBOL was quite leaky. For example, if your array index overran the array boundaries, you could overwrite the executable instructions. Eventually you’d get an "illegal instruction" core dump. The core dump, however, was meaningless unless you knew some assembly language. However, better abstractions over assembly language [b][i]were[/i][/b] possible. For example, I’ve programmed in Java for years without having to look at the code generated by the compiler.

    And similarly, with web development, the solution is not to return to using more primitive tools; the solution is the creation of a better abstraction that simply isn’t so darn leaky. In the mean time, we can use a high-level leaky abstraction whose underlying layers are more humanly comprehensible and friendlier for use by the developer — such as Java with Wicket.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s