I'm referring to the development of high-level components such as user interfaces. These deserve our attention because they increase the value of what we can do with technology. Instead, we're continually re-creating the same low-level infrastructure.
Nobody sees a shared library or a driver, and no one cares about them unless they're broken. Yet that's where developers are focusing much of their time and resources. In doing so, they are making a big mistake--not because these pieces don't deserve resources, but because resources are being thrown at them haphazardly, resulting in waste, not to mention less-than-stellar software. That fact is that much of this software is lacking. Unfortunately, the constant attempts to create and re-create these components generally fall short. And still the resulting products manage to suck up valuable maintenance resources.
The world of shipbuilding offers valuable lessons on how developers might better proceed. When technologies designed for the bow of a ship mature, they move to the rear of the boat. Even so, they retain their value for long stretches of time. These older technologies usually require less innovation but plenty of renovation.
A different approach prevails in the software world, where resources are continually used to reinvent components such as abstraction layers and other parts of the low-level operating system. These components often are not well built--leaving us with back-end products that are too fragile, and which never become robust, even when they're enhanced later on.
This isn't to say that some rock-solid low-level components have not been done--many core drivers and libraries in Linux and Windows XP, such as mass storage drivers and file systems, are extremely robust. But unfortunately, video drivers, multimedia libraries and recent networking features haven't been produced with the same success. And the quality of printer drivers and subsystems can range from very good to reprehensible.
Unfortunately, many current IT efforts seek to reduce costs by perpetuating low-level software that's less standardized and of low quality. This is a self-destructive and outdated concept that's produced few improvements.
Does this mean that we lack the guts to address challenges? I don't believe so. But we need to consolidate our efforts industrywide. It will take decisive leadership and reliance on the open-source development philosophy and tools to help us focus effectively on both innovation and renovation. In doing so, we will be able to concentrate our efforts appropriately, pursuing both design and refinement as warranted by different situations.
The cost of constantly reinventing low-level software (drivers, libraries, hardware abstraction layers and other parts of the low-level operating system) would thus be eliminated. After consolidating our efforts, we'd have room for well-financed and long-overdue robust renovation of the low-level industry-common cores that still need it.
If there's a lesson here, it's to be on guard against lazily lumping together innovation with renovation. By doing so, we get neither a solid engine room nor a fast bow--a mistake no midshipman would ever contemplate.
The big win here would be to kick software innovation into high gear by clearing the decks to focus the innovation segment on the "race to the top" (as Thomas Friedman of The New York Times has put it). People with big dollars then can take big risks for big opportunities.
And in case you don't think it's time yet to confront this imperative, perhaps you should sit back and ponder all the time that you've lost every time your computer jams and you wait anxiously for it to recover. Relax--you've got plenty of time.
William Jolitz co-wrote 386BSD, an early version of the BSD Unix operating system.