Teh Intarwebulatorz Aren’t For Real Developerz. Srsly.

7/7/2012

This old gem just came up agaon on HN. Michael Braude had a go at Web programmers (essentially saying they’re dumber than an ironing board) to which Jeff Attwood responded by saying much the same about non-web devs. Even though I used to be a Jeff Attwood, philosophically I side with Michael. My premise is that it has little to do with smarts, and much to do with experience. Here’s why:

Some of Michael’s points about the lack of complexity in web development are true. Unlike Michael, however, my reasoning is based on design (in the architectural sense) rather than straight-out skill as a developer.

I read anything related to architecture I come across, and these days a lot of it is from start-ups describing how they built their apps*. There are many commonalities about these start-up architectural descriptions – here are a few:

  • Most of them focus exclusively on the technologies used.
  • Most start-up architecture write-ups lack of any kind of diagram (guessing because they don’t know a tier from a layer).
  • Many will eschew security because “security is difficult to get right”. It isn’t. Security is no more difficult than, say, a breadth-first tree traversal, but that’s material for another post.
  • Almost all of them fail to discuss quality goals like maintainability, reliability, extensibility, interoperability, correctness, usability or supportability.

Moving on to Jeff, who went so far as to invent a law:

Atwood’s Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

Jeff goes on to say that:

Writing Photoshop, Word, or Excel in JavaScript makes zero engineering sense, but it’s inevitable. It will happen. In fact, it’s already happening. Just look around you.

I won’t (can’t) argue with this. Google Docs and Office 365 prove it. The drivers for all this web thinking are – amongst others – the things Jeff lists:

[Traditional apps have] to be purchased and licensed and shipped and downloaded and installed and maintained and upgraded.

Some of those apply to web apps as much as they do to old-school thick client apps (“maintained” stands out), but that’s another discussion for later.

In the final analysis, I think this obsession with Web is wrong. It’s wrong and broken in a fundamental way.

The reason it’s wrong is that many young developers haven’t the experience to make any kind of architectural decision beyond what to build and what tech to build it on – and the choice of web over any alternative, as well as platform is driven by trend, rather than suitability.

The big problem facing the web today is security and privacy. Start-up types don’t care, and the average Joe Soap doesn’t know any better. Yet. High-profile attacks (Sony PSN, RSA, Wikileaks, Android.Walkinwat) are raising awareness, but seems it’s not enough to make script kids question their architectural choices.

Then there’s that eagerness to ship. MVP (minimum viable product), it's called. However, the rush to get something out there comes with consequences. Apart from the inevitable bugs and gaping holes, there are ignored considerations like the impact on an end user when they grant access to a web site using a Facebook, Google or Twitter account. They’ve never even heard of concepts such as user control and consent – let alone the laws of identity. They seem incapable of articulating or even identifying the commercial, technical or operational risk involved in using MongoDB as opposed to SQL Server, WCF instead of Node.js, or JQuery Mobile instead of hand-rolled JavaScript. Note that all of these technologies are good and valid choices, in an appropriate context.

When you look at the corporate world you’ll notice that junior devs are thrown at front-end work with the tedious inevitability of puberty – be it WinForms, or Web or any other flavour.

That’s no coincidence.

Leaving the user experience that results from inexperienced developers aside for a moment, front-ends are easy (what can you possibly screw up when all you’re creating are UI components and UI process components?), and the architectural decisions have already been made. There’s a logical progression. You move onto MVC, then maybe MVP or MVVM, followed by the rest of the stack – DTOs, facades, application workflows, components and entities, data access logic and service agents. Most devs get to the non-functional (but cross-cutting) architectural aspects last: operational management (including governance), security and communication.

The really good ones might progress to contemplating business-value trade-offs like those between a message bus and a federated integration model.

Another consequence of inexperience is that these developers build what they think people want, rather than what people need. Sure, some get it right – Mark Zuckerberg is a good example – but he got lucky, which is the exception rather than the rule. And look no further than the German Data Protection Agency to see the mess he’s making with his naïvety.

So, in conclusion: I take Michael’s side – never again** will I be a full-time web dev to the exclusion of everything else. I also acknowledge that web development is no longer as easy as it was in the 90's. HTML, CSS and JavaScript in today's world of cross-browser, pseudo- can-it/can't-it-HTML5 are the most brittle and fussy technologies I've encountered. Jeff, however, could’ve made a much more compelling argument rather than letting himself be drawn into a dick-swinging contest.

* In fairness, much of the stuff I read online these days relates to keeping a handle on technology trends. The fact that script-kids are willing to document their experiences for my benefit is not lost on me.

** I know the feeling very well - I used to be that know-it-all, pimply-faced script kid after building this (entirely JavaScript -based) search tool in 1997.


Home | Blog | Photos | Contact | About

Wittenburg.co.uk and all content copyright 1995-2018 by Michael Wittenburg, unless otherwise stated.
All content on this site is licensed under the Creative Commons license, unless otherwise stated.

Wittenburg.co.uk uses a single session cookie because it's required by the tech underlying the site (Microsoft ASP.NET). The cookie stores no information and seves no functional purpose.