Welcome!

Java Authors: Liz McMillan, Frank Huerta, Elizabeth White, Pat Romanski, Sandi Mappic

Related Topics: Java

Java: Article

Software Should Be More Hard Wearing

Software Should Be More Hard Wearing

I am always in awe of people who develop hardware. They're the real engineers of our profession, the ones pushing forward the speeds at which things work, their size, and their connectivity. For example, in 2005 there were more computer chips produced worldwide than grains of rice harvested and at a lower unit cost. Tonight as I was watching a movie from the 1980s, instead of dating it by the big hair and shoulder pads, the tree rings were most visible by the size of the mobile phone the hero was using, the lack of a plasma or LCD wide-screen TV in an otherwise luxurious living room, and the absence of a satellite navigation device as the lead characters got lost following directions from a map.

Why is it then that we in the software trade have let the side down so badly? Whereas hardware has advanced so dramatically in the last 40 years, I believe that software has stumbled along and, at worst, gone backward in a sort of fashion-driven and hysteria-led fervor. It must drive the hardware guys crazy - each time they achieve a new technological breakthrough with engineering brilliance, the software that runs on their new marvel seems to take the same number of steps backward that they managed to advance.

I remember coding in RPG in the 1980s and struggling to keep response times down so users wouldn't become dissatisfied with the application and bombard our help desk with complaints. If things got too bad, the customer could always upgrade their box to a newer and more powerful model and, riding the wave of Moore's Law with semiconductor speed doubling and price halving every six months, this was always the long stop for poorly performing code. However, as each new box came along with more memory and more processing power, the software somehow became larger and slower, so that the overall response time never seemed to really go down. I always felt sorry for the hardware engineers who with each new chipset probably thought, "Phew, we've just created an X mega/gigahertz chip; now everything that ran slowly before will perform OK, let's take a break," only to receive the call on their vacation that a new OS release or software package had been created that needed their new hardware specification as a minimum and could they please work on the next release to make it perform acceptably.

My mobile phone broke the other day after it fell on the kitchen floor, and after an apologetic call to my network provider, they agreed to send me a new one. Fortunately it wasn't going to cost me anything so I naturally talked myself into getting the latest whiz-bang model. When it arrived I was in awe of the thing: it's super slim, has the most gorgeous anodized case, a viewing area larger than my digital camera's, and as a piece of engineering is a work of art. The software on it, however, is absolutely terrible: to send a message I'm required to open a folder called messages, select "create," then type the message, pushing a button for "options", then pressing "send" again, which then asks me whether I want to send SMS or MMS. From a usability standpoint, it is just appalling. I don't care about network protocol; I want the phone's software to figure out which to use by analyzing the message's content.

There are two buttons on the front of the phone that will connect me to the Internet, one of which I keep pressing by accident when I'm backing up through menus. I don't want to connect to the Internet, ever, so I then have to press another button to cancel this. "Do you want to cancel?" This is the only time the phone ever asks for confirmation and, unfortunately for me, the only time I don't want to be asked. After pressing "Yes," it then comes up with a dialog telling me the number of bytes transferred that I have to press another button to dismiss. Why do I care about the number of bytes? It feels like the thing has a bunch of debug options left on. When I receive a call and the lid is open I press the green call button to accept. If I get a call and the lid is shut, all I have to do is open it and not push the button. Nice touch Mr. Usability Designer, except that if I open it and push the green button because I'm not thinking it holds the call. What is holding a call? All I know is that I can hear them and they can't hear me and I have to now push another button to retrieve the call.

My TV has a recordable receiver that can store shows on its internal hard drive allowing me to watch them at my leisure. This is great and totally changes the way one watches TV; however, when the chaps wrote their software on it they decided that the remote control buttons for changing channels would be up for a higher channel and down for a lower number. Not a bad choice, except the person writing the software to allow the program guide to be viewed used, not illogically, down for higher number channels (as the list is sorted with the lowest number at the top), so there are now two opposite ways to switch channel numbers depending on which part of the device's software you're using.

The list of frustrating software things that plague every existence doesn't end there, and it just disheartens me that the basic task of analyzing, understanding, and tooling for the user's most frequent and simple scenarios seem to have been overtaken by an obsession to cram as much functionality as possible into the hardware, overloading it with slow and poorly thought-through applications. In software we need to stop this millennium's ridiculous obsession with chasing the latest architectural fad or silver bullet that whizzes past, and instead focus on going back to basics and finding out what our users want and giving them something that's reliable, resilient, and more hard wearing.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Carl 02/12/07 01:57:58 PM EST

It's not accurate to say "look at how cool the h/w is" with your cell phone but complain about the "s/w" as if the UI were the only s/w involved. There is so much s/w behind making that phone work, routing calls, cells, protocols, etc. The h/w by itself would be useless. (Then there was all the CAD/CAM software used to design the h/w and its chips and circuits, run the manufacturing process, track production, shipping...).

Similarly with the RPG example; "gee, I still have to worry about poor performace 'cause we've junked up the fast h/w with useless features" - except that nobody wants just paper reports printed out weekly; they want their reports on-demand via the web. That's a ton of s/w behind all that. Do you have any appreciation for the internet and web browsers?

I think that a good part of the problem is the ephemeral nature of software. First of all, you can't see it or touch it, so like with these examples (above) he doesn't realize how much s/w he is touching. It has gotten very much more sophisticated, with layers upon layers of code. If he, as a s/w guy, isn't aware of it, how much less is management above him aware?

Does software engineering have problem? Sure. Would more engineering disciple help? Probably. But since software bits are "free", but hardware costs money to manufacture, it'll probably always be easier for bad software to "escape" (i.e. be released) than bad hardware - especially when the question is "does it work?" and not "does it work well?".

Bill Albing 02/12/07 01:05:40 PM EST

You know, it's not really the fault of the software developers, per se. All your examples have to do with software that has to work with hardware in an integrated fashion, and the companies that make those devices still see themselves as hardware companies not as service companies with solutions that integrate both hardware and software. Until they do, you'll see this disparity between hardware and software advances.
But I agree with you that it would be great if we had the latest software on the latest hardware.

Reema 02/09/07 03:17:08 PM EST

Absolutely agreed! AJAX doesn't do a whit for us if we don't know the basics of UI design...

BK 01/22/07 10:15:27 PM EST

I agreed: hardware folks are real engineers. Software "engineer" are more like "pseudo-engineers". This is related to the fact that software "engineering" practices itself is "promiscuous. What do I mean by that?.
The answer is that hardware engineering is along either you get it right or you get it wrong most of the time i.e it is more stringent. Software on the otherhand can give appearance of being right and give you some functionality till the bugs surfaces.
Also, you can have fairly sloppy programmers/developers producing reasonably good enough application with today's RAD or IDE tools. Hardware's working is more elementary and therefore takes better engineers to understand and design it well.

There, you have it: software allows Tom, Dick, Harry of lower caliber to code; hardware allows only those who knows engineering well to work with it for most part.

Dennis Muzza 01/22/07 06:29:13 PM EST

Yes, hardware engineering is a much more formal discipline than software engineering and there are many things we should be learning from them, but while not trying to downplay their achievements, mastering and harnessing the laws of electronics doesn't present nearly the same kind of challenge as figuring out the best way to arrange and present information to us fickle humans. While we still have a long way to go in the field of usability, looking at the achievements of the last 30 years (Lotus 1-2-3, Mac, Linux, Google, and a long etcetera)I don't think software professionals as a whole should be particularly ashamed.