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:
- 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.)
- 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.
What we need to do is accept that a lot of the “non-functionals” are no longer that.