There has been growing anxiety among many in the U. S. software industry over the last several years. As more developers hear of software jobs being outsourced overseas, perhaps even losing their own jobs to lower cost producers in other countries, their concerns about the future have deepened, even as the overall American economy has experienced sustained growth.

Outsourcing software development projects to companies in other countries (India, for example) is attractive to Corporate Information Officers because it offers the prospect of dramatically lower costs. Software development is a labor intensive activity, and it can be all too easy for financial analysts to focus on the wage differences from one country to another. Those wage differences are certain to have a significant effect on the U. S. software industry for years to come. Now hold that thought for a moment, while we shift to a topic that at first appears to be completely unrelated.

For the centuries that the Roman Empire ruled much of the world, Latin was of course the language of government and commerce. But its influence extended centuries beyond the time of the last Emperor in Rome. Throughout the Middle Ages and to the modern era, to be considered truly educated a person had to have some knowledge of Latin. Although it wasn’t the everyday language of life, Latin did provide access to the knowledge and wisdom of the ancient world. The language of Cicero and Virgil was still widely taught in public schools through much of the 20th century. Even today, many private schools include Latin in their curriculum, and Latin course materials for homeschoolers are readily available.
(As an interesting aside, there is even a Latin version of Wikipedia at
http://la.wikipedia.org/wiki/Pagina prima ).

So what does a “not-so-dead” language have to do with outsourcing IT?

Well, one problem faced by CIOs seeking to outsource software development is the need to clearly define the requirements for a specific project. Actually, that is a problem for any software project, but the difficulties are amplified when the team members are from different cultures and bring different presuppositions to the project. The problem faced by any organization that seeks to off-shore software development is the need to communicate requirements unambiguously.

An American requirements analyst working in Silicon Valley thinks she has clearly described the system’s architecture, but her team members in New Dehli, despite speaking impeccable English, read her words to mean something significantly different from what she had in mind. The premise of off-shoring software development is that if a specification has been written that clearly defines the system’s requirements, and if a design has been developed that is thoroughly informed by a deep knowledge of the problem domain, then there are likely to be many people in the world who can write the code to implement the system, at a significant cost advantage. However, the difficulty of achieving such specifications is not to be underestimated.

One scenario of what the near-term future holds for software developers in the U. S. is that they will find themselves spending less time coding and more time specifying and continuously clarifying requirements. Understanding the specific needs of the customer and translating them into the available technology have always been among the toughest challenges of software development, and those challenges will only grow as advancing technology allows the industry to tackle ever harder problems.

In this scenario, the next generation of American developers will still learn Java, not so much so they can write code in it, but so they understand what can be coded by their overseas teammates. Thus Java (or some other computer language) becomes a means of communication between those specifying the software and those coding it.

Software artifacts tend to have a life much longer than their developers ever anticipate; witness the enormous body of Cobol and Fortran code that still runs daily. Once a particular problem has been solved and solved well, it is not uncommon for the code to be passed along from one project to another.

It is not difficult to imagine snippets of Java used as idioms for communicating design intent long after the language itself has become obsolete as a primary tool for system development. Therefore, just as Latin had a utility for scholars long after it had ceased to be commonly used, Java could become a type of lingua franca for communicating design intent among team members who differ widely in their native natural languages.

For help with homeschool computing, visit us at StrongTower Software .