Technical Credit

There’s a well-known concept in programming that refers to the negative effects poorly-made decisions can have on the quality of software over time: Technical Debt. The Wikipedia article gives some examples of the causes and the consequences of technical debt.

This financial analogy is a useful one, as it nicely describes the long-term impact of debt – the longer you have it, the worse the problem becomes. Conversely you can have credit (e.g. savings) in your account for a long time, waiting for the proverbial “rainy day” to take advantage of your good planning. Want to splash out on a new pair of sparkly galoshes? No problem!

At the An Event Apart conference in Orlando in October 2016, Jeremy Keith spoke about "Resilience: Building a Robust Web That Lasts" which was a talk about progressive enhancement cleverly disguised as it didn’t use the phrase ‘progressive enhancement’. In that talk Jeremy dropped a knowledge bomb, calling building sofware using the principles of progressive enhancement like building ‘technical credit’.

This, in my opinion, is genius. It’s a gloriously positive spin on technical debt, which is too often seen as the product of bad developers. It’s saying “you, developer, can make a better future”. I love that.

It appears there is little online which talks about this “technical credit” concept. In fact, the only decent resource I could find is a 2014 paper from the Conference on Systems Engineering Research entitled ‘On Technical Credit’. The author, Brian Berenbach, gives a brief but eloquent introduction to the idea that we should concentrate on what should be done, rather than what shouldn’t be done to make a system better.

From the abstract:

"Technical Debt" … refers to the accruing debt or downstream cost that happens when short term priorities trump long term lifecycle costs… technical debt is discussed mostly in the context of bad practices; the author contends that the focus should be on system principles that preclude the introduction, either anticipated or unanticipated, of negative lifecycle impacts.

Sounds great; let’s stop bad things happening. How? The abstract continues:

A set of heuristics is presented that describes what should be done rather than what should not be done. From these heuristics, some emergent trends will be identified. Such trends may be leveraged to design systems with reduced long term lifecycle costs and, on occasion, unexpected benefits.

Emphasis mine. I’ll wait here while you to read the rest of the document.

At this point hopefully you can see the clear link to the principles of progressive enhancement. Let’s look at a few examples emergent trends – which I’ll call ‘properties’ as the paper uses this term – and the (un)expected benefits that progressive enhancement may give. But first, a quick refresher on what progressive enhancement is.

The principles of progressive enhancement

I can’t put progressive enhancement in a neater nutshell than Jeremy does in his talk ‘Enhance!’:

  1. Identify the core functionality
  2. Implement it using the simplest technology possible
  3. Enhance!

For websites this boils down to practical principles like these:

But there’s no hard-and-fast set of rules for progressive enhancement, because every site has different functionality. That’s why it’s considered a philosophy rather than a checklist. As Christian Heilmann said, progressive enhancement is about asking "if" a lot.

Emergent properties

Someone once said words to the effect of "the only constant is change", meaning that the only thing you can rely on is that things will not stay the same. That’s good! Progress is positive and brings with it new opportunities.

These opportunities can be seen as emergent properties – new or existing attributes of things which emerge as time goes on. For example, the increasing uses of mobile computing devices and fast home connection speeds are emerging properties leading to opportunities for new types of business. Likewise, the prevalent use of social media and its unprecedented bulk collection of data about its users is allowing new models for advertising – and, unfortunately, more nefarious uses – to emerge.

These emerging properties are often very difficult if not impossible to predict. Progress can lead to unexpected outcomes. Technology in particular is often put to unanticipated uses and exhibits unexpected behaviour when used at scale.

Who, for example, could have predicted the explosion of new devices and form factors just a few years ago. Devices once the domain of science fiction are now commonplace, and the range of new input types – notably touch and voice – is revolutionising how people interact with technology.

While fixed line download speeds are increasing many in developing nations, who arguably are the ones who could benefit the most from widespread Internet access, are stuck with very slow speeds, if any at all. Clearly we have a long way to go to achieve parity in global access to the Internet.

(Un)expected benefits

With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer. The ‘On Technical Credit’ paper defines this approach as Technical Credit:

Technical Credit is the investment in the engineering, designing and constructing of software or systems over and above the minimum necessary effort, in anticipation of emergent properties paying dividends at a later date.

This is Progressive Enhancement. It’s about putting some thought in up-front to ask those tricky "what if" questions. Questions such as:

Thinking about these, and many other, potential problems leads you to follow the recipe given by Jeremy which I quoted above:

  1. Identify the core functionality
  2. Implement it using the simplest technology possible
  3. Enhance!

Implementing core functionality using the simplest technology possible – in the case of a website by using well-structured semantic HTML markup generated on the server – gives some expected benefits:

Plus it provides a strong foundation to take advantage of unexpected occurrences; those emerging properties mentioned earlier.

From brand new browsers to old browsers working in a new way, your well-structured HTML will deliver your content even if everything else fails. Support for new input types on a myriad of unimagined devices will be taken care of by the browser – rather than you having to find Yet Another JavaScript Component™ that adds the support you need. And as new APIs are added you can layer on support for these knowing the foundation of your site is rock solid.

Spending Technical Credit

So you’ve built your system carefully, thinking about the many ways in which it could fail. You’ve done ‘over and above the minimum necessary effort’ and can now sit back, confident in the hope that should a rainy day come you’ve accrued enough technical credit to weather the storm.

I Am The Very Model Of A Modern Web Developer

I am the very model of a modern web developer
I build my sites in Ember or in React or in Angular
The download size is massive but development is easier
My grunt and gulp and NPM all prove that I am geekier

I am the very model of a modern web developer
My animations cause offence in anyone vestibular
A carousel with massive pictures should be seen as de rigeur
And light grey text with background white will make my content sexier

Some people say my websites should all be enhanced progressively
But my developmental choices have been made deliberately
A 12 meg payload is a guarantee of exclusivity
I don’t want Luddite users who refuse to upgrade from 2G

I have a brand, you could say I’m an Internet celebrity
But try to load my site on anything but super fast 4G
You’ll just get empty pages on your Android or your iPhone 3
Upgrade your phone, you pauper, or you’ll never get a byte from me

With apologies to Gilbert and Sullivan.

HTML Matters

Rant time. No-one can deny that web development tooling has improved in leaps and bounds over the last few years. I’ll sound like a moaning old man if I talk about how primitive things were in the old days, so I won’t.

But despite this wealth of tools, loads of good quality information online, and access to resources and training why do I still regularly see HTML like this in new web projects:

<div class="footer">
<span><img src="twitter.gif" /></span>
<span><img src="facebook.gif" /></span>
<span><img src="instagram.gif" /></span>

It appears modern web developers have within their grasp a panoply of development and build tools – NPM, bower, gulp, grunt etc – but don’t have access to HTML elements which have been implemented in browsers for years. HTML matters!

It matters because structure matters. Meaning matters. Semantics matter (but don’t go overboard). Accessibility matters. For many projects, SEO matters.

A web page is, at it’s core, a structured document. Pile on all the fancy-pants JavaScript frameworks you want, but you’re still delivering HTML to a rendering engine built in a browser. If you’re making no effort to use appropriate HTML elements to mark up your content then you need to sharpen up your skills.

Wednesday is Link Day

It’s been a while, so here’s a humongous list of goodies for y’all.


Performance Testing Dictionary, a free book (registration required):

Yes, a performance budget builder:

Measuring performance (using the navigation timing API):

Aligning app performance to business success (podcast):

Performance advice from experts:

A good case study on performance improving the bottom line:

The “average page” is a myth:


This 1939 Chart Explains How Color Affects Legibility:

What’s coming up for Microsoft Edge in 2016. Number 2 on the list: Accessibility:

What to do when you get sued for your inaccessible website:

The BBC gives advice on how to design for accessibility:

The business case for issue prevention: Extreme Accessibility:

Accessibility for business and pleasure:

The browser accessibility tree:

Progressive Enhancement

A simple enhancement for ordering items by, who else, Jeremy “My Man Crush” Keith:

“JavaScript web apps considered valuable”:

“Why I hate your single page app”:

“Don’t tell me what my browser can’t do”:

Progressive web apps by Google (I may have linked to this before):


Mobile and Multi-device design: a free e-book (on Apple devices only, bah):

The world’s poorest households are more likely to have a mobile phone than a toilet:

As mobile screen size increases, so does activity:

Launch an Android app from the web and cleanly fallback to web:


Shared before, but still great. Offline access to documentation:

Give developers autonomy. Couldn’t agree more:

Want to write software for your car? It’s coming:

The history of Open Source, and a glimpse at its future:

The woes of date input (yep, got that t-shirt):

“Paid a great deal to be terrible at development most of the time”:

The art of debugging (presentation and video):

Martin Fowler on feature toggles:

Control CSS filters with HTML attributes:

Developer fallacies:

The sad state of entitled web developers:

Most developers have never seen a successful project:


Via Beth: what’s next for manual testers:

On screen reader testing:


“Design without touching the surface”:

Great talk by Jen Simmons about getting out of our design rut:

CSS best practices presentation:

The Goldilocks approach to responsive design:

About notifications and no-UI:

The dangerous UI team:


We need to really understand promises:

Offline with ServiceWorkers and UpUp:

2016 – the year of streams:

Definitive guide on charts in JavaScript:

const and immutable objects in ES6:

Regex in JavaScript made easy:


Old-school PC fonts:

Online regular expression tester:

Stupid hackathon. Featuring my favourite Chrome extension “Non-Ad Block”:

A feature detection library in 1KB:

Images and sketches of popular mobile devices (from Facebook):

And finally…

Remember Command and Conquer? Here it is in HTML5:

A briefish history of the web (in 3 parts):

Play a drum machine with your keyboard. And record it. Yes:

And if that wasn’t good enough, here’s a TR-808:

Free philosophy e-books. Cos I know you love ’em:

What Tor’s data looks like as it flows around the world:

The web is OK:

Tuesday is Link Day!


Presentation on “Smaller, faster websites” by Mat Marquis:

The website obesity crisis (presentation):

What developers should know about performance:

What I’ve learned from monitoring four years of web page bloat:

Articles about how web performance affects revenue:

Avoiding Temptations that Harm Website Performance:

Progressive enhancement

Jeremy Keith hits a million nails on the head: “Server-side rendering is not a fallback; client-side rendering is an enhancement.”

What “progressive web apps” mean for the web:

Interaction is an enhancement – an excerpt from Aaron Gustafson’s new book:

The article that first described progressive enhancement:

Reimagining Single-Page Applications With Progressive Enhancement:


The modern web is broken for people with disabilities:

Mozilla accessibility QA engineer tells us what the basics of accessibility are:

Learn about accessibility in just 20 minutes:

On accessibility and the lack of proper HTML:

Free web accessibility tools round-up:


Why you shouldn’t bother creating a mobile app:

The App-ocalypse: Can Web standards make mobile apps obsolete?:

Instant Loading Web Apps with An Application Shell Architecture:


Dark Patterns: fighting user deception worldwide:

A rant: how are website still screwing up these user experiences:

Simple inline error message pattern:

Three principles for using design successfully. No 1: Start with design, and don’t just end with it:

Brad Frost is writing a book on Atomic Design, which you can read for free here:

How to make sense of any mess, a free online book on information architecture:

Beyond the style guide:

How to do a UX review:


Psychological pricing strategies (mammoth set of tactics!):

The perfect storm in digital law:

What customer experience excellence looks like: “Customer experience is 10% technology and 90% culture”:

Helping VIPs care about performance:

Teams/general development

Rachel Andrew on confidence and getting overwhelmed:

What RESTful actually means:

What do we ask in Stack Overflow:

Yahoo gets rid of QA:


A useful JavaScript glossary:

Microsoft open sourcing the Chakra JavaScript engine:

An “operating system”, with lots of apps, in JS:

“Every JavaScript project you should be looking into”:

Amiga emulator in JavaScript, with games:

The service worker cookbook: “a collection of working, practical examples of using service workers in modern web apps”:

You don’t need jQuery:

4 JavaScript design patterns you should know:

Use React? here’s a cheat sheet:


Flexbox Froggy – learn flexbox with a fun game:

Flexbox support is pretty good, except for IE:

And there’s now an IE 8/9 polyfill:

Web components that can be built purely using css, NO Javascript:

“Just add water” CSS animations:

Tools and resources

Security Panel debuts in Chrome DevTools:

Dictionaries and Word Lists for Programmers:

Some good videos to watch, mostly JavaScript:

Big list of “free for development” services:

Use console.table for easier logging:

SpaceHolder – A space-themed image placeholder service:

How to use Chrome DevTools like a Pro:

Each year this online advent calendar has fantastic articles:

And so does this performance-specific advent calendar:

And finally

History of the web:

See websites in old – I mean REALLY old – browsers:

GCHQ going open source?, a typing game:

For the geek in your life: Star Wars Kama Sutra: