Recently a small post on Slashdot concerning an article by Dan Crawford, on the performance of modern dynamic languages in general and JavaScript in particular, showed up and Dan’s site was quickly “slashdotted“. The next day the article was followed up with an article by Shai Almog who worked (among other things) with Sun on JIT compilers for mobile platforms. Tempers are running hot, so I guess we haven’t reached the end of this discussion yet.

What the whole discussion is about, just to get down to the basics of it, is whether dynamic, interpreted languages will ever get on an equal footing with something like C, on a mobile platform. The central discussion is concerned with memory management; where Java popularized an approach where you don’t have to clean up (or even: can’t clean up) behind your back, because a Garbage Collector will do that for you. If you are a Software Developer or Architect and like reading a well-researched article about the dangers of over-reliance on features such as Garbage Collection, please do read Dan’s article.

What got me thinking, was the vehemence as well as the technical focus of the discussion, for something non-techies are more-and-more getting interested in: non-functional requirements.

Ok, maybe I need to get this out of the way first:

1. I like several languages that employ a Garbage Collector, including Java and Modula-3. (Actually, several parts of the major Modula-3 implementation, including the GC it employed, were used for the early releases of Java.)
2. I am a strong proponent of using the right tool for the job, as opposed to having a single tool to solve all your problems. If anything, Ada should have taught us the dangers of that approach.

This post is not about the performance of specific platforms.

Functional versus Non-Functional

So we all know about “requirements” and the fact that they specify what the customer wants implemented in the application, but what about the difference between “functional” and “non-functional”? Usually the customer specifies the functionality needed, either in a requirements document or a functional design, or else in the form of a user story. Information Architecture (or, if you like, Software Architecture) concerns itself with the requirements you don’t see as directly visible functionality, called non-functional requirements. In Wikipedia they are described as the requirements that specify “criteria that can be used to judge the operation of a system, rather than specific behaviors“. Well-known examples of non-functionals are security, performance, maintainability, availability, and scalability.

The discussions in the articles referenced above are then clearly of interest to the architect of the system, rather than the customer. Right? So why do I see customers talking a lot about requirements which are clearly non-functional? I actually sat in a Kick-off meeting for a project targeting the refresh of several websites, where the requirements list specified mostly performance related requirements. What happened? Is the customer displeased with the current site’s performance?

Panta Rhei (“Everything Flows”)

What I think is happening, is that we’re being confronted with the consequences of moving applications to the Web. The Internet was designed to be a resilient infrastructure, allowing communication between systems even when parts of the network aren’t working. As a consequence, “Quality of Service” concentrated on getting the data from A to B rather than getting it there on time. Where gamers have been known to call out the effects of network lag since the earliest forms of Internet games became available in the nineties, most people just wanted to see the page they called up in the browser, accepting delayed visibility of e.g. images and blaming it on their (relatively) slow Internet link.

However, as Heraclitus (oh why do we insist on writing Greek names with Latin grammar as well as letters? “Ἡράκλειτος” ends in “os”, not “us”. Need to resist urge for a rant…) made famous, everything changes. Our Internet speeds have improved dramatically and building a site includes building it for fast delivery, just in case the network link or server is less optimal. This aspect has moved up front-and-center so much, the general public has started accepting fast responses as a matter of course. Clicking a link or button not responding within a few seconds? Click again! Is the page taking a long time? Ridiculous! Thanks to Microsoft Windows’ predominance on the desktop/laptop market, coupled with the frequent problems experienced, reported, or just perceived surrounding performance, we have been trained to first suspect our own computer, then the remote site. If a site disappoints us more than a few times with slow response times, we try to find another site to give us what we want. Alternatives are often available in abundance, so keeping the user on the site means we have to take performance serious.

So: How Functional are those Requirements?

I’d say a lot of non-functional requirements have become down-right functional! Performance, security, availability, privacy, you name it. The genie is out of the bottle: non-functional requirements are important to the customer, because their customers walk away, if we don’t deliver. Management or even board-level discussions will talk about them up-front, because it directly affects the baseline.

Now back to those discussions on Slashdot: what is happening here? Sure, the technical content of the discussion is important, but even more important is the vehemence of the discussions. These discussions draw the attention of the non-technical crowd, and the semi-technical “translators” are likely to transform the discussion into something along the lines of “Mobile and Web application performance is still a hotly debated issue and there are basic problems with platforms like Java and JavaScript that may be at the root of it.” That message is definitely not the correct interpretation of those articles, but we techies love those debates so much, we tend to forget who we are serving. We don’t serve our customer by “throwing more iron” at a badly performing application, especially if we made them drool with the client-side functionality of HTML 5 and JavaScript.

What we need to do is accept that a lot of the “non-functionals” are no longer that.