HTML apps and the 50 year software engineering legecy

I no longer call myself a ‘software engineer‘ but I do consider it to be a vital part of my career background. To my mind, engineering provides the rigour and discipline aspects of being a developer, the other parts being the craftmanship of software and community social interactions with other members of a project/product team.

To be fair I’ve been a round a while; from my first early tentative hacks of 6800 assembler listings of a BASIC interpreter, through commercial development of mission critical mobile data systems, to open development of accessibility and HTML apps. Along the way I’ve picked up a number of  good practices as projects got larger and more complex. Some I rapidly unlearned (eg Waterfall & V models, Yourdon, Jackson), others have stood the test of time (eg modular encapsulation, OOD, unit testing) and new ones have come along (eg Open Development, Agile methods, TDD, Human centred design). These great thing is these all apply regardless of technology used.

My Big App

My Big App

So it was interesting to suddenly notice a year or so back that at conferences like the first jQueryUK conference how HTML developers are starting to wrestle with some of the problems already experienced by previous software developers. The issues are arising as we attempt to build apps in HTML technologies, layering javascript heavy designs on top of the declarative basics of HTML and CSS.  The issues are those that occur when you move to development-in-the large. For example, the need for modules, and namespaces, relying on the scaffolding of 3rd party libraries or frameworks, cross platform (browser) support and handling the social aspects of working in teams or open projects.

I guess it’s a new generation coming along and many grew up on the cut-n-paste hackiness of the early web. Now the problems have got bigger and more serious so the approach needs to change. To solve this, a number of libraries/frameworks have become the first port of call for developers trying to make life easier on complex HTML apps. Some of  these plug serious gaps in the language such as the lack of modules required for design in-the-large (I’ll deliberately not mention class based OOD here). Others provide abstraction and encapsulation of the messiness of the web, but these often work in almost purely programmatic ways, ignoring and replacing the strengths and principles of declarative HTML.

Some large monolithic libraries pull in masses of code even if not needed, this having a bad affect on load performance sensitive usages, such as mobile. For example jQuery (and jQueryMobile) undoubtedly make a developer’s life simpler in many ways, but are monolithic. Now, however the original purpose it served, namely using CSS declarative syntax for DOM element selection, is now available natively in browsers with element.querySelectorAll(). Plus native can be faster at run time and without the loading overhead. Another example is how the javascript code for forms handling, especially validation, is often not necessary due to HTML5 improvements.

John Allsopp neatly picks up on this topic in his recent post recent post ‘Is HTML Relevant in the Age of Web Apps?‘, neatly highlighting the impact of sucking in all this code complexity.

As the systems we build increasingly replace traditional enterprise, client server, desktop and mobile apps (yes it will happen), this luxury of building disposable code, with no real concern for the tower of complexity our code rests upon, will pass.

It’s time for us to grow up, and start learning from the more than 50 year legacy of software engineering.

Because, as with all history, if we don’t learn from it, we are doomed to repeat it

So how can best learn the required good techniques? “4 Things I Wish I Would Have Known When I Started My Software Development Career” by John Sonmez, the Simple Programmer outlines 4 mistakes I’ve made myself in my career (and for some still have a tendency to do).

  • There is no “right way” in software development
  • Reading a book cover-to-cover is not the best way to learn
  • Learning particular technologies in-depth is a waste of time
  • Always have a side project

 

ActuaCC2elly, one book that it probably is worth reading cover-to-cover is Steve McConnell’s labour of love ‘Code Complete: A Practical Handbook of Software Construction. I must admit I’ve only deep-skim-read it but it’s full of perfect gems of software construction mined from the coalface and lovingly presented for your delight. I have a scruffy old copy of the 1st version but Steve has updated it and I expect it’s even better. Not at all bad for a book that only cost’s £24.48 at Amazon.co.uk 

 

Use Code Complete for a side project with an open source project that practices community driven open development, and you’ll soon be on your way to learning from that legacy.

Engineer on.

This entry was posted in development, HTML, opensource, web. Bookmark the permalink.
Skip to top

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *