When Moore's law finally fails, will software get better?

By now, almost everyone has heard of Moore's Law, which is often intepreted to mean that our computers will double in power every 18 months (or 24 months depending on who's intepretation you are using). This "law" has held up for 40 over years and is still gong strong.

Every few years, the scientists who work on the front lines of integrated circuits look forward and see a potential wall that limits how far current integrated chip technologies can take us. So far, those same scientists have been able to adapt new techniqies and new technologies to blaze paths around those walls. From a hardware point of view, and from an consumer electronics point of view, this is the best thing since... well the integrated circuit.

I am not a Microsoft Basher (or apple basher, or google basher or...) and I make my living developing software. But I sometimes wonder if our real world computer experiences wouldn't get a lot better if Moore's law was to fail for a few years.

The ever increasing hardware allows us to mask software bloat. Next years hardware will be 50% faster than this years. So, we can hide bloat that eats up, oh, say 20 or 30% of that increase. Iin a year or two, that 30% loss won't even be noticed.

BUT (yes, this is a big BUT) , to misquote a favorite political truism: a gigahertz worth of bloat here and a gigahertz there and pretty soon it starts to add up to some real horsepower.

I know many of you are reading this and thinking of Microsoft, and that is fair, Microsoft Windows and Office have more than their fair share of bloat. The the problem doesn't end there.

Software in highly competitive markets live and die by features.

Performance is important, but only in a relative sense, how does my performance line up with my competition? If our code bases are equally bloated, then performance drops out of the evaluation critieria and it's back to front lines where features and perceptions win or lose the day.

If we couldn't rely on newer, faster, cheaper hardware to hide the bloat, we would have to go back and do things right. The feature wars would slow down, and software would once again begin to differentiate by concentrating on different features for different kinds of users. Software companies could get out of the escalating arms race where every competitor's newest feature has to be countered yesterday.

Damn the Bloat! Full speed ahead... That is the attitude that is forced upon most engineers in the software industry. I think almost all software engineers would love to step back and be allowed to design software that really helps our end users, rather than constantly scrambling to counter our competition's latest moves.

Don't read this the wrong way. In general, today's software is a much better experience than the software of a decade or two ago. But, it's far short of what it could be. Far short of what we should be able to do with all the computer horsepower at our disposal.

Tags: computer, engineering, Moores Law, pc, software

Stardock: A Must for the Colorblind

I'm partially colorblind, and a few months ago, I became really sick of the standard Windows XP themes, that all are either really annoying, or use colors that I have trouble seeing.

About 6 months ago, I decided to look for a solution. I started with the standard windows XP theme sites. During the search, I managed to trip across: Stardock ... It took a while sorting through the hundreds of available themes, but finally I found Cha-Ninja. It works great for my particular version of color blind (I can't distinguish between blues and purples or between greens and browns) and I happen to like the aesthetics as well.

So, all of you who happen to be colorblind, or partially colorblind. Take a look at Stardock. Even their free packages can make windows a much friendlier place for the color challenged. I've purchased their full suite and have no intention of ever giving it up.

Tags: Computer, Colorblind, PC, Stardock, Software

Develop Tools for the End Users not for problems

I guess it falls somewhere under teaching an old dog new tricks. But, my current project has forced me to re-evaluate some of the tactical decisions we have made in previous projects.

A bit of background: We are currently working on development of a software system to help fix some of the process problems in hospitals. And believe me, hospitals are target rich environments for process improvement.

The unique twist here is that we have to allow non-technical hospital employees to build and maintain fairly complex process rules. This forced us to start thinking of the tool from the real end users capabilities and work backwards to the actual system. The net effect is that the system is modeled after every day, commonly understood abstraction that help to minimize training. We have been very diligent at eliminating complexity where it was not needed, and especially at avoiding anything that even smelled of "programming".

I know this sounds like a common sense thing to do, but it doesn't normally happen that way, at least not around here. In the past, our approach would have been to build a tool to match the problem first, and then back in to administrative capabilities and training necessary to allow our customers to do their jobs. The result was almost always heavily dependant on the idea that our target audiences would want to solve the problem badly enough to "stretch themselves" a bit to learn how to manage the new system. While this was sometimes true, in retrospect, it limited our customer audience to those few who were willing to do so. The rest of our prospects would tune us out, when our sales pitch started to look complicated.

This time around, the target administrators were so different; we had to keep the end user in mind every step of the way. To accomplish this, we tried to picture nurses using each new feature before it was put into the tool set. We don't know if nurses will actually be maintaining these rules, but we have designed the system so that nurses could maintain them with minimal to no training.

While it is still early days, the result of this approach to the problem is very promising. The software module in question is not a hurdle, and in fact nurses attending some of our presentations have specifically said: "I could do that!".

Also, the clean, simple abstraction we followed, has allowed us to pick up this new software and plug it into an existing, well established Call Center technology that our company also sells.

Lesson Learned: In the future, I will try to design all of my systems with the end user foremost in my mind and will strive to eliminate any complexity that that audience would not already be prepared to deal with. I know that will not always be possible, but it should be the rule, not the exception.

Tags: engineering, software