Job (in)security

Story

June 24, 2008

Dr. Kevin Nilsen

Atego Systems

Software engineers' resistance to promising new technologies like Java is more a matter of job protection than carefully reasoned technical evaluation.

I've been promoting the benefits of the Java language for real-time mission-critical - and even safety-critical - development for more than 10 years now. The development teams that have heard the message and switched to Java have found that they are more productive during new code development and up to 10 times more efficient during Java code maintenance. They also find their programs have fewer bugs and are less brittle. Finally, they discover that it's much easier to hire competent Java programmers through university recruiting programs, and that they are able to exploit the huge and growing libraries of COTS and open-source software components written in the Java language. This is a huge benefit since the Java language boasts the largest availability of reusable software components and the greatest ease of integrating these reusable libraries. These developers are finding that Java brings them good things.

Despite these benefits, Java adoption by the real-time community has been slow, and over the years, I have often asked myself why. Compared with programs written in Ada, C, or C++, most Java programs easily adapt themselves to new operating environments and functional requirements - characteristics that extend the software's useful lifetime, further increasing returns on the software development investment. Faced with the need to evolve the capabilities of a legacy C or C++ application, programmers are much more inclined to simply discard the software and write something new in its place. I'm driven to wonder if one of the biggest obstacles hindering the adoption of the Java language for real-time development is resistance by developers who feel that their jobs might be threatened.

Many programmers are perfectly satisfied with frequent rewrites of existing software systems. They are not at all ashamed that the code they themselves wrote less than five years ago is no longer relevant to the evolving needs of the customer. In fact, they might even be rewarded by their management for reaching this conclusion. After all, if the customer needs a complete software rewrite, that's more money for the company, adding profits to the team's bottom line. Where is the incentive to write code that is general, maintainable, and scalable? Where is the motivation to reuse COTS software components rather than implementing every capability as a custom-tailored solution, multiple times?

I can see why developers might worry about the longevity of their jobs if a simple switch of programming languages allows their companies to accomplish the same amount of work with a staff less than a quarter of its current size. This is scary, indeed. But what is more scary is how much productivity and defense department spending are wasted on these misguided attempts to preserve job security.

We've been working with a large defense subcontractor for a number of years to help them establish general directions for corporate-wide technology adoption. Recently, we were called in to help resolve some difficulties in integrating a large infrastructure component implemented in C with a large application component implemented in Java. It turned out that the company had already invested many man-years of development in both the Java and C code. The C and Java code were written by two different teams of developers, at different corporate sites. There was a certain amount of pride and "turf" associated with the respective components. The integration of the C and Java code seemed to work correctly as long as the Java code was running on a non-real-time virtual machine. However, when they tried to run the Java code on our real-time virtual machine, certain problems arose.

It was interesting to watch the interplay between the Java team and the C team. The C team was reluctant to investigate the integration problems. In response, the Java team began threatening to throw away the C infrastructure code and rewrite the entire infrastructure in Java. This escalated the conflict. The C team responded that there was no need to switch to a real-time virtual machine: Stick with the non-real-time virtual machine and continue to use C for all code with real-time requirements. All of a sudden, I understood why it had taken several years of interaction with this company to get even to the point of understanding their struggles. The entire team of C developers was feeling threatened that their special skills might be made redundant by the ability to write real-time software in the Java programming language.

Within a week after this discovery, we managed to identify the problems in the handoff between the Java code and the C code. It turned out that the C code was exploiting proprietary features of the non-real-time Java virtual machine, and the C developers were assuming that all virtual machines would behave the same. The problem was easily fixed.

Unfortunately, the bigger problem is a much more difficult problem to address, as it may stem from a similar complex psychological response to personal insecurities that affect the entire industry: that of motivating the entire defense software industry to exploit superior technologies to save government costs and improve war-fighter capabilities.

Software engineers who feel threatened by newer technologies that promise higher productivity and lower software development costs might do well to take comfort from the experience of the PC industry. Driven by the pressures of competitive differentiation, the large majority of the cost savings yielded by Moore's law during the past 40 years has been invested in the development of faster and more powerful computers rather than simply producing cheaper computers with the same capacity as the previous generation. For the foreseeable future, there is more than enough work to keep existing software engineers gainfully employed on interesting and important projects.

Dr. Kelvin Nilsen is CTO of Aonix, a mission- and safety-critical solutions provider, where he oversees the design and implementation of the PERC virtual machine and other Aonix embedded/real-time oriented products. Prior to joining Aonix, Kelvin served on the faculty of Iowa State University where he performed seminal research on real-time Java that led to a clean-room Java technology and the PERC family of virtual machine products. He earned a B.S. in Physics from Brigham Young University, and both M.S. and Ph.D. degrees in Computer Science from the University of Arizona. You can reach Kelvin at [email protected].

Aonix North America, Inc.
858-457-2700
www.aonix.com