Turning Desktop Developers into Web Developers
I’ve been doing a lot of Webforms (ASP.NET) development over the last four months, as I’ve mentioned in some posts. Before that, I was doing a lot of WPF development for desktop applications and before that a hodgepodge of things that included web development with the Java stack. I had done very little with Webforms (though I had dabbled with a couple of internal corporate applications), so wrapping my head around it has been interesting.
For those of you not familiar with the way Webforms works, it could probably best be summarized as “helping you write web applications without realizing that’s what you’re doing.” Okay, that might be a bit snarky, so let’s go with “making windows desktop developers comfortable with writing web applications.” (in particular Winforms developers). It goes out of its way to create an abstraction layer that represents web concepts as their desktop equivalents which, I believe was done with the intention of easing the transition of a generation of Winforms developers to web application development. And, well done. I think it was wildly successful at that.
But not with Webforms. Webforms evens the playing field using wizards, WYSIWYG and extremely involved abstractions to make everyone working on a Webforms project a Webforms developer. Webforms actually abstracts understanding of underlying concepts away from the developers in this fashion, the way that Front Page and other such code generation tools have in the past. Karl Seguin gives an excellent Webforms vs ASP MVC summary that touches on these points and others.
A Brief Foray Into Architectural Philosophy
Persistence technologies, messaging/communication with externalities, web vs desktop are all non-core implementation details. Oh, don’t get me wrong, they’re important. But ebay doesn’t have an Oracle DB application or even a web application — it has a consumer resale application. The core of their business is enabling resale and that transcends the current technology stack. If Oracle went out of business tomorrow and a unified web became passe, ebay would no doubt try to soldier on by switching to MySQL and peer to peer app communication (or whatever). If people stopped wanting to resell goods, on the other hand, ebay would be kaput.
To staff a project that scales beyond tiny (i.e. multiple developers and up) a sensible way to divide up the work is to have some core business rules programmers and then others specializing in various satellite aspects of the application. So ebay might have people that develop server side application/business logic, people that specialize in Oracle stored procedures and people that specialize in web as a delivery mechanism and it would be expected that those people be domain experts, database experts and web experts, respectively. (Not to say that there couldn’t be some fluidity among these groups according to skill-set or availability and learning curve).
This separation of skills required in a team environment allows for the pairing of team members with tasks for which they are best suited. These pairings, in turn will naturally tend to foster productive collaboration, division of labor and generally good morale. People, especially knowledge workers like software developers, prefer autonomy and that tends to exist in greater abundance when each team member has a unique skill set that he or she is applying. A project with an architecture like the one I’m describing is more likely to be staffed by happy and productive developers.
Webforms and Generalist Mediocrity
Webforms does not lend itself well to the sort of architecture that I’ve just described. It invites developers to use controls that completely automate and obfuscate the generation of client side markup and scripts. But beyond that, it invites developers to describe the persistence layer in the specialized markup as well (the various “data sources” and their wizards), in effect flattening the application and rendering it monolithic. As such, Webforms developers can be (can be — not must be, please don’t misunderstand my point) relatively low-knowledge generalists whose only specialty is, well, Webforms. Webforms itself is the one with knowledge of different application layers and architectural patterns.
Image by “Scottius11” via wikimedia commons.
Whoah. Let’s think about that for a minute because it’s actually fairly profound. In a Webforms project, it is Webforms itself (or, more accurately, the people who designed ASP.NET) that understands the technologies involved. Webforms is your most knowledgeable ‘stakeholder’. Most successful frameworks and architectural technologies offer a cafeteria plan of sorts to let developers pick and choose what they need and want and to allow people to be paired up with particular facets of an application (a lot of IoC containers and various toolkits have this property). They empower developers. Webforms instead offers them a crutch — a way to perpetually develop applications without really understanding how they work.
Imagine that you owned dogs all your life but decide you want a cat. Now imagine a team of engineers coming along to ease the transition. They build a wooden “Trojan Dog” with a litter box in it so that you can “walk the cat” to get it to go to the bathroom. They build a sound altering muzzle so that when the cat meows, it sounds like a bark. They give you toys and pants loaded with catnip so the cat will ‘retrieve’ the toy and bring it back to you in game of ‘fetch’. In short, they create all manner of pretty elaborate and impressive adapter tricks to allow you to own cats and pretend that they’re dogs. They probably also do a bit of hand-waving when asked why this scheme makes any sense.
The Genius And Fatal Flaw
Like the hypothetical “dog to cat transition technology”, the Webforms abstraction of all things web is impressive. It’s impressive for a group of developers to be able to create a technology that allows tens of thousands of people to write applications without really understanding the underlying technology stack (again, not in all cases — just saying it’s possible). It’s impressive for those developers to create something that allows other developers to generate a radically different type of application without having to learn much in the way of new skills. I can’t overstate that — it’s amazing.
But the same thing that makes it amazingly effective at bringing old school Winforms developers into the 21st century also limits their growth and that of the applications that they produce. Webforms is a “helicopter parent” that doesn’t, on its own, know how to stop telling its 17 year old child when it’s time to brush his teeth and wash his face, and thus it runs the risk of perpetuating learned helplessness in the same. The internet is no longer new and alien, and our web development toolbox should reflect that.