network-characteristic gratuitous degradation and broken-first development

 There used to be a web design principle "graceful degradation".  The idea was that web sites could be made so that a richly-functioning web site, should it find itself on a user agent not supporting every aspect of the platform it wanted, still worked well, doing the best it could with the features available.  No web site was ever created that adhered to this principle.  The weak thinking behind the "principle" was representative of everybody involved in creating the edifice of shit passing for the "architecture" of the web.

There followed a related design principle, "progressive enhancement".  The idea with this one was that a web site should function correctly on a minimal set of platform componenets (not that anyone would or could know what that minimal set consisted of, in general or per site).  If the user agent happened to support additional features, the web site was allowed to use these to enrich the experience.

Neither design principle is relevant now, because you just have to have the latest version of the google one, the apple one, or the other one.

But a related design method has taken off, and is taking the agile world by storm.  In a way, this is a specialisation of the "broken first" methodology.  In "broken first", a developer makes a big, complicated, confused pile of not-workingness.  Then they tinker with it, until it only just works, on the specific setup they are using themselves.  It remains broken on every platform and version other than the exact one they just got it working on.  Later, their team-mate, who is using a  different client configuration, notes it doesn't work for them, and the implementation gets changed so it also works on this setup.  It remains broken on everything else.  After several more iterations thru this agile process, the big pile "works" on an impressive number of very specific setups, each setup necessarily including configuration happenstance.  Common configurations of the big four browsers often end up working, sometimes up to several point releases of each one.  For everything else, the site remains broken.  That is the broken first methodology.  In the beginning, it is broken for everything.  Later, it is unbroken for the particular implementation and configuration quirks of certain specific setups, and only those setups.

Having reminded ourselves of the definitions of graceful degradation, progressive enhancement, and broken-first development, we are now in a position to define our new term: gratuitous degradation.

Gratuitous degradation is when a web site stops working because a feature it doesn't need is not present.

This can also be understood in terms of broken-first development.  Suppose a web site is "unbroken" for a specific setup.  We might classify the changes into two basic categories, which we can call "specific unbreaking" and "incidental standards implementation".  Specific unbreaking means those changes that rely on particular quirks of the platform the web site is being unbroken for.  Specific unbreaking changes are the best appraoch within the broken-first methodology.  Incidental standards implementation is when the agile developers take a shortcut by implementing part of some standard, instead of catering to specific quirks.  This is not strictly correct in the broken-first methodology, because it can lead to accidental unbreaking of the web site on platforms other than the one being targeted.  Gratuitous degradation is when a web site correctly reverts to its broken state because a condition that is not conceptually required for operation, but just happenned to feature in one of the unbroken setups, no longer applies.  Gratuitous degradation is a key sign of broken-first development: if you do not see gratuitous degradation regularly, the developers have probably been cutting corners.

One common class of gratuitous degradation is network characteristics dependence.  The web site may have been unbroken for Trevor's setup in the office next door, connected directly to the same LAN.  It has probably even been unbroken for Peter's home DSL with 30ms round-trip and 10 Mbps thruput.  But it won't have been unbroken for mobile coverage on a train, or a slow or intermittent connection, or higher packet loss.  Don't even think about DHCPing around or continuing a session later.  Most modern web sites, however simple conceptually, do not get unbroken for speeds below around 8 Mbps or round-trip times above 75ms.

Which brings us finally to blogger.  You might quip that it's degrading enough to be using blogger in the first place, but can we leave that aside for now.  Blogger has some classic cases of network-characteristic gratuitous degradation.

For speeds below several several Mbps and / or latencies above several tens of ms and / or packet loss above a few percent (I haven't measured the exact conditions, nor am I likely to), the "New Post" button does: nothing.  It just does nothing.  This is classic gratuitous degradation: silently doing nothing is one of the most effective application responses in a non-supported client profile scenario.

I went thru the usual user paths: pressing the same button lots of times, reloading, trying out other web pages to see if I had some sort of connection, and so on.  Then I wrote something in my local editor.  Half an hour later, the New Post button was working: it brought up the authoring editor, and I was ready to discover the second piece of graceful degradation (presumed network-characteristic too) on Blogger for the day.  I pasted in my title.  I pasted in my article text.  I prepared to press the post button.  And everything disappeared.

So there it is: Google's slickest asset Blogger, gives us a cutting-edge synthesis of two of the most exciting trends in modern software development: network-characteristic gratuitous degradation, and active clipboard sabotage.