Skating to the puck

I recently reviewed an internal study of competing technologies for a new, large-scale, Windows application. It was the typical survey of the possible platforms for the application, summarizing the strengths and weaknesses of each. This kind of analysis has been done hundreds (or thousands, or tens of thousands) of times by companies and organizations around the world and back to the dawn of computing. The thinking is: Before we set out on this project, let's review the possible technologies and pick the best one.

As I was reading the study, I realized that the study was wrong.

Not wrong in the sense of improperly evaluating technologies, or wrong in the sense that the authors ignored a possible platform. They had included the major platforms and listed the strengths and weaknesses in an unbiased presentation.

It was wrong in the sense of time. The report had the wrong tense. It looked at the present capabilities of the platforms. It should be looking at the future.

The project is a long term project. The development is planned for five years, with a lifetime of ten years after that development. (That's a simplified version of the plan. There will be releases in the five year development phase, and enhancements and maintenance during the ten-year follow-on phase.)

For such a project, one needs a view of the future, not a view of the present. Or, as Wayne Gretzky learned from his father: "skate to where the puck is going to be, not to where it has been."

The study looked at the major technologies (.NET, Java, Silverlight, Air, and Flash) and reviewed their current capabilities. The authors made no projections of the possible futures for these platforms.

I understand that predictions are hard. (Especially predictions about the future.) But the majority of the development effort will be made in the future, from two to three years out, and continuing for a decade. Looking at the current state of technologies and deciding the next fifteen years on them is insufficient. You have to look at where each technology is going.

This study was part of a new development effort, to replace an existing product was difficult to maintain. The existing product was about ten years old, with parts going back fifteen years. The difficulties were due to the technology and design decisions that had been made at the inception of the project and during its life, some only a couple of years ago.

This team is embarking on a repetition of their previous development effort. Instead of creating a long-lasting design on robust technology, they are building a system that, in a few years, will be difficult to maintain.

Pucks move and technology changes. If you always skate to where the puck currently is, you will always be behind.

Not with a bang

Has the Age of Windows passed? I think it has. Not only that, I think the age of the web application is passing. We're now entering the age of the smartphone app.

In the past, transitions from one technology to another have been sharp and well-defined. When IBM released the first PC (the model 5150) companies jumped onto the PC-DOS bandwagon. Products were either ported from CP/M to PC-DOS or made for PC-DOS with no attempt at compatibility with the older systems. (A few perhaps, but the vast majority of applications were made for PC-DOS and the IBM PC.)

When Microsoft introduced Windows 3.1, manufacturers climbed onto the bandwagon and created Windows applications and abandoned MS-DOS. Windows 3.1 was a "windows thing" on top of the "DOS thing", so the old MS-DOS applications still ran, but all new applications were for Windows.

(I'm ignoring certain technologies, such as OS/2, CP/M-86, and the UCSD p-System. I'm also ignoring Macintosh, although I suspect that the Apple II/Macintosh transition was also fairly swift.)

Back to Windows. Since the rise of Windows, we've had one major transition and we're in the midst of another major transition. The first was the shift from Windows (or client/server) applications to web applications. The second, occurring now, is from Windows and desktop web applications to mobile web applications.

The shift from client/server to web app occurred slowly. There was no "killer app" for the web, no counterpart to Lotus 1-2-3 that pulled people to PCs or network support that pulled people to Windows 3.1. The transition was much slower. (One could argue that the killer app for the web was Google, or YouTube, but it is a difficult case.)

Back to Windows. I think that the Age of Windows is over. Think about it: all new applications are designed for either the web or a mobile phone (usually the iPhone).

Don't believe me? Try this test: Name a major commercial application designed for Windows that has been released in the past year. Not applications that run in a browser, but on Windows (and only on Windows). I was going to rule out applications from Microsoft, but I cannot think of new applications for Windows, even from them. (New versions of products don't count.)

I cannot think of any new applications. I can think of new applications for the web (Facebook, Twitter, DOPPLR, etc.) but these live in the browser, and none of them are tied to Internet Explorer. The iPhone has oodles of new applications, including games such as Labyrinth and the Ocarina player. I don't know of anything significant in the commercial space that is specific to the iPhone, but I suspect that it is coming.

But its more than just a move away from Windows. The market has moved, quietly, from Windows to web apps. Windows applications join their older cousins written in COBOL for "big iron" in the maintenance yard. That's old news.

The market is moving again.

As I see it, Facebook is the last major desktop web application. By "desktop web application" I mean an application that was designed for a web browser on a desktop PC. Faeebook was certainly designed that way, with the iPhone version as an afterthought.

Twitter, on the other hand, was designed out of the gate as an iPhone application, with the Windows client as a concession to the technical laggards.

The creativity has shifted to the smart phone. New applications will be made for the iPhone and other smart phones. The talented developers are thinking about smartphones, not desktop web, and certainly not Windows. Older platforms such as the desktop web and Windows are now "mature" platforms. Their applications will be maintained, but the platforms get nothing new. The new applications will be designed for smartphones. A few apps may carry over from the smartphone, but it will be difficult: smartphones have mobility, position awareness, and a degree of intimacy not available to desktop users.

Not with a bang, but a whimper, does the curtain fall on Windows. And desktop web applications.

Upper bounds

Sometimes, our environment limits us. Sometimes our physical capabilities limit us. It's good to know which, because a limit in one can reduce the usefulness of plentitude in the other.

For example, our visual system limits our ability to channel surf on a cable network. These limits create an upper bound on the number of channels that we can use on a cable network.

Why? Because we can surf only so fast, and therefore surf a finite number of stations in a given period of time. Let's assume that I can surf from channel to channel, spending one half second on each channel. If I start at channel 2 and work my way upwards, it will take me some amount of time to reach the end and "wrap" back to channel 2. With twenty channels, it takes ten seconds. With two hundred channels, almost two minutes. With a thousand channels, about twenty minutes.

If we had ten thousand channels, it would take the better part of a day to surf them. By the time we decided on a channel, the program would be long over.

Here's the interesting observation: With a thousand channels, by the time one surfs the entire collection, the original program (if a thirty-minute show) is more than half over. We have spent too much time surfing and not enough time watching. ur physical capabilities (the ability to process a video signal and decide to stay or go) creates an upper limit to the number of channels.

That limit holds for the strategy of surfing. If we use a different strategy (perhaps looking for specific programs or types of programs, or using an index, or relying on a TIVO-like prediction system) then we can use a larger cable network.

This effect comes in to play with a lot of things, not just cable television. The web is a large collection of channels. The applications on the Apple iTunes store is a large collection. Books in a bookstore. Videos on Youtube (or Hulu).

Books and web videos don't have the time-limit of television programs, yet we all have finite time, finite resources to spend on viewing, listening, processing, or reading. We are all constrained to make choices in finite time.

The trick is knowing our limits.

Revisiting Babel

Is it possible to move faster by going slower? The concept defies our intuition, yet such a thing may be possible.

For example, on one recent project a team made significant progress. The details were related to me at the Open Source Bridge 2009 conference. I won't go into them here, as they are not important. The important point is that the team completed its task, faster than expected, and under budget.

This progress was surprising as the different team members came from different countries and spoke different languages. They all spoke English, and used it as the common language for the project, but none were fluent in it.

How could such a team make any progress, never mind rapid progress?

The speculation is that since English was a second language, team members spent more than the usual amount of time listening to other members. Processing a second language is often harder; one must pay more attention and often ask for clarification.

The simple acts of listening and asking for clarification may have made the difference.

Old tech fails in interesting ways

During a recent visit to a local (and well-known) hospital, I happened to spy an old LA-75 printer. These were made and sold in the mid 1980s. They were considered the low-end printer, selling for $700 or so. (The letter-quality printers went for quite a bit more.)

Hospitals are health care providers, and therefore fall under HIPAA rules. HIPAA is very specific about security of patient records.

I wonder if hospitals know that dot-matrix printers are not secure? That is, there is an attack for dot-matrix printers.

By carefully recording and analyzing the sounds made by the printer, one can reproduce the text printed. The attack is called the "Acoustic Side Channel Attack". I suspect that it can be done by simply placing an Apple iPod into "record" mode and sitting it in the same room as the printer. Later, by analyzing the sound (even with background noise), one can identify the text printed during the day.

You can see more details here.

Mind the infrastructure

In our mad rush to the future, it is too easy to become distracted by shiny new tech and ignore the stuff that we already have. Shiny and new is interesting, and the current stuff is boring.

E-mail is probably the most boring of our current systems. Like other utilities, it consistently does its job. It's there for us, all of the time.

Except when it isn't.

I've been working with a national staffing/placement/recruiting company. A big company, one with a name you would recognize.

And their e-mail system is broken.

Not completely broken, but definitely not whole. Their e-mail system has been rejecting messages for three days now. Not just messages from me, but from lots of people outside of their company. Some messages can get through, others cannot. In-bound messages are affected; outbound messages work as you would expect. Internal messages work. But not a good situation, especially in their line of business.

This firm has two problems. The first is that their e-mail system is broken. Like many other companies, they use e-mail for their normal work. With these problems, people must resort to alternative communication means: phone calls, voice mail, and fax. Data transfer is just about impossible, as their placement specialists have no skills with FTP or other data sharing technologies. The loss of e-mail has a significant affect on their business.

The second problem is a little more subtle: Their e-mail system has been broken for three days. Their system administrators are not able to resolve the problem.

Are you starting to worry yet? Here is a company that uses some old, boring tech to run their business. It breaks, and they cannot fix it. (Or they cannot fix it quickly.)

I don't believe that this company will go under because of an e-mail outage. But can any company afford to lose business in the current environment?

It's easy to see how this situation can happen. A company builds an infrastructure. The system works well, but requires expenditures to keep it running. Well-meaning budgeters reduce the allocation of resources. Maybe they lay off the technical lead, or assign him to other projects. Everything still works.

Until it doesn't.

Let's bring this closer to home: What infrastructure do you count on? How well is it supported? Have you cut back on the administration and support teams?

Now are you starting to worry?

Keep an eye on the infrastructure. Know what it is, and make sure that you have people who can keep it running.

iPhone apps raise the bar

The process of installing an application program has changed over time. It started simple, then became complex, then became complicated ("complicated" is worse than "complex"), and now it is simple again.

Installing an application DOS was simple: buy the application on floppy disks, create a directory, copy the files from the one or two floppy disks to that directory, possibly create a batch file, and you were done. The batch file usually used a CD command to change to the directory and then ran the program. Advanced users created batch files to CD back to a common directory when done.

Later DOS programs came with their own install batch files, and sometimes install executable programs. Put in the first disk, type "INSTALL", and away it went! When finished, you could run the program (usually with a batch file that the install program made). But you still had to buy the application on floppy disks, still run the install program, and still interpret the UI.

Microsoft made things consistent in Windows, first by standardizing the name of the install program to "SETUP" and later by standardizing the target location to "C:\Program Files". And during the Windows era, applications grew and moved from floppy disks to CD-ROMs, and later to DVD-ROMs. (But the notion was the same: buy the media, insert, run SETUP, and possibly pick some options.)

The folks at Apple have raised the bar. Not only in the user experience for the application, but the experience of buying an application.

First, with the iTunes store, Apple has created a single place to distribute applications. This is one-stop shopping, with no problems in finding a specific web site for a specific application.

Second, Apple has reduced the steps of purchasing and installing an "app". You go to iTunes, pick your application, pay for it, and it is installed across the network. You don't need a CD. You don't need a system administrator. You don't need a standards committee. You don't have to think about directory names, license keys, or other distractions.

Third, Apple has made applications fun. Beyond the obvious fun apps such as "Labyrinth" and "Ocarina", the basic platform for iPhones, iPods, and Macintoshes encourages applications that please the user. (When where you last pleasantly surprised by a Microsoft application?)

Fourth, Apple has made "apps" small and inexpensive. The small apps can be had for one dollar, many for less than a McDonald's Happy Meal. (Big applications are still expensive.)

After using the Apple platform and "getting spoiled" by the ease at which one can install applications (and do other things like work), the Microsoft platform looks clunky. Microsoft products are big, expensive, install-with-questions beasts.

Microsoft's attempts to hide things from the user (such as with Windows Vista) is well-intentioned and the right direction, yet too many details poke through. The Linux distros (especially SuSE and Ubuntu) have done good jobs, but they also can use some improvement.

Apple has raised the bar, once again, for the user experience. The first question is: can Microsoft and Linux keep up? The second question (for developers) is: can you?