Last week I talked about some of the problems with our current and future IT workforce. To summarize: there is a growing structural imbalance between the demand for information technologists and supply. Rapid growth in IT, especially in the U.S., has caused companies to outsource a large share of IT jobs, as well as take advantage of the increasingly controversial H1-B program to import extra workers. Notwithstanding the upheaval this has caused in the domestic IT job market in the last five years, it will provide only a temporary fix as cheaper workers are consumed and salaries are equalized globally.

Some companies have developed educational partnerships and sponsorships to develop new talent, but for reasons that I outlined last week, this will provide only limited results. If information technology is to live up to its potential, the industry will have to figure out a better way to develop and use the available workers.

Last week I also talked about the inherent limits on the number of people who would be suitable for IT work. Short of genetic engineering, there's not a lot to be done here. But there is at least one other facet of the problem that we can do something about. It involves how information technology advancements outpace the ability of the workforce to adapt to them.

The rapid advancement of technologies is especially stressful to older, more experienced IT professionals, since it tends to obsolete their skill sets. For example, developers who have worked for years in C/Unix/RISC shops find employers are reluctant to hire them for Java/Linux/x86 work. And regrettably, employer-provided training or retraining is almost non-existent in the industry. Part of this comes from management's view of IT workers as technicians rather than engineers and the feeling that younger or foreign-born talent will be cheaper. The unfortunate side effect of this kind of treatment is that it discourages new talent from entering the field. Employer-provided training and a little more professional respect would go a long way to keep the current supply of IT workers productive.

Then there's the problem of IT workers being consumed by what I'll call unproductive work. An example of this is software porting. It's a problem that is continually being (re)solved as developers lug legacy codes from platform to platform. Although this is a necessary task, I would suggest that it's not the best use of our limited workforce. These individuals would be better employed developing new application software, or at least enhancing current codes.

The Itanium experience is a poster child for this type of activity. The new processor architecture needed an entire software ecosystem and application domain to be transferred from older technologies. Consider the time, money and other resources Intel, HP and others have invested in making the Itanium processor a viable product in the market. Just this year, the Itanium Solutions Alliance infused $10 billion to do just that.

One way to reduce the human costs of porting software would be to develop emulation technology for the new platforms. Some of these technologies exist today and are in use. QuickTransit (Transitive Corp.) allows code compiled for one processor architecture/operating system to run on a system with a different processor architecture/operating system without source code or binary changes. In fact, one of the QuickTransit implementations dynamically translates Solaris/SPARC apps to Linux/Itanium ones. Supposedly the translation retains up to 80 percent of its native performance. But even if it were much less efficient, the translated code might still outperform the same code that is run on the older architecture. Emulation represents a valuable technology to offload a lot of tedious work from software developers.

Rapid technology advancement also manifests itself in another way that challenges the IT workforce. Hardware performance and capacity is increasing much faster than our ability to develop software to take advantage of it. This requires a constant effort by developers to find new ways to exploit overachieving processors, growing memories, and speedier networks. Perhaps even more challenging, the paradigm shift to parallel processing that is being propelled by multi-core and multi-processor architectures is creating additional difficulties for our current crop of software developers.

Even cyber-optimist Ray Kurzweil admits that software is currently running behind hardware. He estimates that software development productivity is doubling every six years, while hardware price/performance is doubling ever year.

In the past, the answer to the dichotomy between hardware performance and programmer productivity has been to raise software abstraction, that is, to encapsulate code complexity in higher level structures. I suspect that this is still the best overall strategy. The speed of microprocessor advancements suggests that we should be much more aggressive in trading application performance for developer efficiency. FLOPS, while not free, are cheap and getting cheaper. Software developers (yes, even the ones writing code in Bangalore, India) are relatively expensive.

But since we moved from assembly code to high-level languages over 50 years ago (Fortran), no other general-purpose programming model has emerged to significantly increase software abstraction. Maybe that's not fair. There certainly have been a number of refinements that have contributed to better productivity: modularization via libraries, object-oriented design and generic programming. These were incorporated into a number of 3rd generation high-level languages like C++, Java and Python. Python, in particular, was designed to emphasize the importance of programmer productivity over code performance.

A number of domain-specific languages (DSL), such as SQL, XML and Mathematica, have become popular in their various disciplines. DSLs trade off general-purpose expressiveness with simplicity, thereby raising the level of abstraction. This type of specialization it likely to increase in the future, since DSLs can open up application development to non-IT professionals.

Not everyone agrees that raising the level of abstraction is a good thing. Some users, especially those with supercomputing applications, tend to be performance junkies. But in the latest issue of CTWatch Quarterly two articles, "What's Working in HPC: Investigating HPC User Behavior and Productivity," and "Observations about Software Development for High End Computing," came to somewhat different conclusions regarding the importance of code performance versus code development. Even for the HPC crowd, the tradeoff between productivity and performance is not always obvious.

Others, though, are just philosophically opposed to the whole idea of simplifying the coding process. In a recent Technology Review interview, Bjarne Stroustrup, inventor of C++, raised doubts about using simpler programming languages in order to allow broader participation. Here's what he had to say on the subject:

"I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous.... Obviously, we don't want our tools -- including our programming languages -- to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals -- not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs."

Damn, that seems a tad cynical. It also seems to reflect the attitude that complex applications necessitate complex tools. But how can that be true? Consider the relative simplicity of DNA. Using a language based on just a few nucleotide base pairs, DNA is able to encode extremely complex living organisms (like for example, Bjarne Stroustrup). Even programming languages themselves are usually much less complex than the applications derived from them.

And while software abstraction can reduce performance, there is a way for software to fight back. Dramatic improvements in the speed of applications can be achieved through algorithm acceleration. For example, the radix-2 Cooley-Tukey algorithm increased the efficiency of the Fast Fourier Transform (FFT) by a couple orders of magnitude. Improving algorithms can provide what Georgia Tech's Mark Richards and MIT's Gary Shaw refer to as "worm-holes in development time," achieving the equivalent of years of hardware advances with a single change to a piece of code.

Bernard Chazelle, professor of computer science at Princeton University, is another algorithm evangelist. Chazelle thinks that computer science, while currently in the doldrums, is actually on the cusp of a great revolution. According to him, what the field really needs a visionary -- someone who could galvanize the public's imagination and express the importance of computer science for our future.

Says Chazelle: "I think that computer science bears an uncanny resemblance to pre-Einstein physics. Moore's Law ... put computing on the map. But algorithms are going to unleash computing's true potential. I predict that there will be an Einstein of computer scientists. The revolution is yet to come."

-----

As always, comments about HPCwire are welcomed and encouraged. Write to me, Michael Feldman, at editor@hpcwire.com.