How buildings learn... and automakers do not

Stewart Brand, in his book How Buildings Learn, analyzed buildings ... and identified ideas that are applicable to all sorts of systems. He noticed that buildings consisted of multiple layers, some which change easily and some of which are difficult to change. (For example: the furniture inside of a building is easy to change, the plumbing fixtures less so, and the locations of plumbing fixtures are even less easy to change.)

The idea of "layers of change" works for systems other than buildings. Just about any non-trivial system has layers of different change.

Automakers have, I think, failed to learn this lesson.

Recent models of automobiles now include wonderful electronic goodies such as navigation systems and interfaces to cell phones. But I fear that the automakers have designed these goodies in a low-change layer -- they expect their electronic additions to last the lifetime of the car.

The problem is that electronic gadgets are "cycled" on a more frequent basis than automobiles. The average life of a cell phone is something under two years; the average life of a car is quite a bit longer. (My automobile is twelve years old, and still in good shape. But my driving is less than the norm.)

The disparity of these two cycles means that a few years after the purchase of an automobile (yet well before the end of its useful life), the "goodies" will seem outdated. (Think about the usefulness of an iPhone 3 in today's world.)

I suspect few car owners will be happy with out-of-date electronics, especially if the (then new) phones cannot talk to their cars. I also suspect that automakers will upgrade systems only in exchange for large sums of money, and possibly not at all.

The lesson here applies to software. Most software systems exist in layers, some easy to change and others less so. Simply tacking on another layer is not enough. We must consider the technologies involved and our customers' desire for new generations of technology. Failing to do so will result in the equivalent of a modern-day automobile with outdated electronic gadgets, whatever that equivalent is in software. It also results in unhappy customers, or whatever that equivalent is in software systems.

Off the top of the screen

In a recent conversation with a (somewhat younger) colleague, I uttered the phrase "scrolled off the top of the screen". I wanted to convey the notion of information that was not available at the present, but was available in the past.

As I used the metaphor, I realized that my (somewhat younger) colleague had most likely never used an honest-to-goodness real text-only terminal. With today's large-memory computers and graphic environments, the ability to scroll up and see previous content (for some types of windows) is taken as granted. But in the old days, when computers were large boxes locked away in secure rooms, users interacted with terminals, and terminals had limited memory and limited display capabilities. So limited that they displayed text in only one font and had no scrolling. (What you saw was all that there was.)

On these terminals, new text (usually) appeared at the bottom. When the screen was full of text and new text appeared, the top line was removed, all remaining lines were moved up one line, and the text appeared in the new, now blank, line at the bottom. This action was called "scrolling", named so because it mimicked the action of terminals that used paper in long rolls.

It strikes me that the verb "scroll" was kept when windowing environments displayed text that could be moved up and down.

But I digress. Let us return to the notion of information that is not available at present, but was available in the past.

Consider the programming skills needed to build data structures. I spent a good deal of time in college developing, testing, and debugging programs that built data structures and sorting algorithms. Today, such structures are baked into languages. Perl, Python, Ruby, C#, Java, and even C++ with its STL extensions all have data structures and sorting, available to the developer essentially "for free".

Asking an aspiring programmer to build such structures seems a waste of time, similar to asking an author to build their own typewriter or a taxi driver to refine their own gasoline. We have better things to do than to re-invent elementary constructs that are available (and debugged).

These skills of data structures have scrolled off the top of our collective screen. At least for the general developers.

General developers do not need to learn these skills. (Nor do they need to learn assembly language, or the ASCII code, or proper writing for programming sheets.)

But someone has to remember them. Languages like Python have these constructs, but they are available because someone put them in the general library. The Python language rests on the Python library, which in turn rests on libraries common to multiple languages, which in turn rest on functions provided by the operating system which in turn rest on functions private to the operating system. But there is an end, a definite stopping point. It is not "elephants all the way down".

Some language engineer must be available to add basic constructs to the language, and that means that some engineer must know the concepts. Skills may scroll off the top of the screen for the typical developer, but as an industry, we must retain them.

We're going to need an attic.

Which slice of the market can you afford to ignore?

Things are not the same in computer-land. The nice, almost-uniform world of Windows on every desktop was a simple place in which to live. With one set of development tools, one could build an application that everyone could run.

Everyone except for those Apple folks, but they had less than five percent of the market, and one could afford to ignore them. In fact, the economics dictated that one did ignore them -- the cost of developing a Mac-specific version of the application was larger than the expected revenue.

Those were simple days.

Today is different. Instead of a single operating system we have several. And instead of a single dominant version of an operating system, we have multiple.

Windows still rules the desktop -- but in multiple versions. Windows 8 may be the "brand new thing", yet most people have either Windows 7 or Windows XP. And a few have Windows Vista!

Outside of Windows, Apple's OSX has a strong showing. (Linux has a minor presence, and can probably be safely ignored.)

The browser world is fragmented among Microsoft Internet Explorer, Google Chromium, Apple's Safari, and Mozilla's Firefox.

Apple has become powerful with the mobile phones and dominant with tablets. The iOS operating system has a major market share, and one cannot easily ignore it. But there are different versions of iOS. Which ones should be supported and which ones can be ignored?

Of course, Google's Android has no small market share either. And Android exists in multiple versions. (Although most Android users want free apps, so perhaps it is possible to ignore them.)

Don't forget the Kindle and Nook e-reader/tablets!

None of these markets are completely dominant. Yet none are small. You cannot build one app that runs on all of them. Yet building multiple apps is expensive. (Lots of tools to buy, lots of techniques to learn, and lots of tests to run!)

What to do?

My suggestions:

• Include as many markets as possible
• Keep the client part of your app small
• Design your application with processing on the server, not the client

Multiple markets gives you more exposure. It also forces you to keep your application somewhat platform-agnostic, which means that you are not tied to a platform. (Being tied to a platform is okay until the platform sinks, in which case you sink with it.)

Keeping your application small forces your application to a minimal user interface and a detached back end.

Pushing the processing part of your app insulates you from changes to the client (or the GUI, in 1990-speak). It also reduces the development and testing efforts for your apps, by centralizing the processing.

This technique has no surprises, perhaps. But then, it also requires no magic.

After all, which market segment can you afford to ignore?