Last month I came to you as a developer as opposed to a CEO. Well, this time I'm moving up the social ladder and I'm writing in the capacity of a user. I'd like to tell you a little story that scared the living daylights out of me. Continuing on the "Ally McBeal" theme from last time, I have seen a glimpse of the future, and all I can say is, "I am troubled."
I was out walking in the middle of London. It was a beautiful, sunny day. Ever since I upgraded my old analog mobile phone to a nice, shiny Nokia digital phone, I've found myself using it more often. Couple this with the fact that I have one of those headsets for the phone that allows me to stay on it for hours without the fear of blowing my head off with the fallout from the nuclear reactor held to my ear.
I love my Nokia. This is the popular one as seen in the movie Armageddon and the one Mulder, from "The X-Files," uses to ask Scully various useless things. It's filled with features. Lots of different features, and a great display. It's everything I never knew I wanted from a phone.
Back to London. I had just finished a call to the office, which inspired another call to be made. I took my phone in hand and moved the cursor up and down the address book with all my contacts in it (which was previously beamed from my PC straight into my phone). However, the whole phone froze. Completely hung on me. The display was still alive, but all my buttons where dead and - even more frightening - my on/off switch was rendered useless.
I had to pop the battery off and back on again to return the machine to life. It then burst back as if nothing had happened. So what went wrong that required me to reboot my phone?
Short answer: Who knows? Chances are, even Nokia doesn't know.
As more of our appliances become more reliant on software, we run the risk of adding more features than beta testers can realistically debug effectively. Are we going to have video recorders hanging in the middle of recording, or toasters crashing as they brown bread? I hope not.
But why is it that, as the features get richer, the bugs exponentially increase. Surely we should be spending more time getting what we have working before adding new bells and whistles. Or is the pressure of continually evolving products so great that companies are taking the risk of bugs in favor of the overall dazzling product?
As you all probably know, Java was not destined for the environment it's running in now. It was originally conceived for the very appliances we're experiencing problems with. Maybe it's about time Java came full circle and completed the job it started out to do. As these devices become far more flexible and functional, the risk of them falling over is also increased.
We don't wish to get to the level of stability that some...mentioning no names...desktop operating systems offer us today. How different the world would be if every time we went to make a cup of coffee we had to debug the kettle!
I just hope we never get to the stage where we have to download the latest patch for our washing machine from the manufacturer's Web site so we can wash our whites brighter than white. Can you imagine how complex shopping for household appliances would become when we're comparing version numbers of vacuum cleaners? A sorry state of affairs. How about virus checkers for appliances? Imagine having the RED day virus, which on a given date washes all your clothes at the highest possible temperature. It may sound far-fetched and silly now, but in five or ten years' time, let's see how silly it is then.
The future is based on software. The hardware is probably going to be the most stable part of the system, but let down by poorly written software. Some say writing bug-free code is possible; some say it isn't. I'm in the camp where you can write software only as good as the environment will allow.
We need a tool that will help us, work with us - and hopefully catch a lot of the silly errors before the end user even gets near it.
Is Java that tool?
About the Author
Alan Williamson, JDJ's "Straight Talking" columnist and a member of the JDJ Editorial Board, is CEO of n-ary ltd, a Java consultancy company with offices in Scotland, England and Australia that specializes solely in Java at the server side. Alan is the author of two Java Servlet books and has contributed to the 2.1 Servlet API. He can be reached at [email protected] (www.n-ary.com) and welcomes all suggestions and comments.