What Is Adatran (or AdaTRAN or AdaTran)?

Adatran (or AdaTRAN or AdaTran) is a metaphor for the failure to make full and proper use of the features of a new technology caused by using it as if it were an existing, older technology with more limited features with which one is more familiar and experienced. The name Adatran (or AdaTRAN or AdaTran) comes from the Ada programming language being used as if it were the Fortran (or FORTRAN) programming language, circa the 1990’s. This informal paper explores the nuances of meaning of the term, its history, and my intended usage of the term as a general metaphor for adoption of advanced technology in general, beyond simply the particular case of misusing Ada as if it were FORTRAN.

[My apologies to anyone whose first name is Ada and whose last name is Tran — I see that there are 10 profiles on LinkedIn for individuals with that name!]

FORTRAN was a much simpler, unstructured, procedural language invented in the 1950’s, pre-dating modern programming techniques, software engineering, and modern software methodologies, while Ada was a modern, object-oriented programming language explicitly commissioned by the U.S. Department of Defense (DOD) to bring modern software technology and software engineering and methodologies and practices to the development of complex applications for the U.S. military. Others could use the language as well, but its whole reason for existence was to support the U.S. military.

Ada, named after Ada Lovelace, credited as being one of the first computer programmers, possessed many new and advanced features which had no analog in FORTRAN. Software developers skilled in FORTRAN were given minimal training and then resorted to using Ada as if they were still coding in FORTRAN, making little or no use of the object-oriented and software engineering features of Ada.

There were a number of possible causes for Adatran:

1. Minimal or weak training in Ada.
2. Training using analogy, showing how features of FORTRAN can be very easily mapped directly into features of Ada, but without thinking through whether this is really exploiting the advanced features of Ada.
3. Insufficient training in the philosophy and benefits of the new and advanced features of Ada.
4. Insufficient time and staff to become more thoroughly acquainted with the new and advanced features and benefits of Ada. Raw schedule pressure.
5. Too much attention on features of Ada rather than on methodology and modern software engineering in general.
6. Insufficient examples of how to upgrade existing programming metaphors of FORTRAN to more appropriate metaphors of Ada.
7. Individuals are still “thinking in (the mindset of) Fortran” rather than “thinking in (the mindset of) Ada.” A change of mindset is definitely needed, but difficult to arrange. It takes both commitment and time. And management and social support as well.
8. An explicit goal to “use Adatran as a teaching tool.” Sure, it gets more people onboard more rapidly, but at the longer-term cost of not taking advantage of the new and advanced features and benefits of Ada.
9. Lack of methodical code reviews with explicit technical criteria for proper exploitation of the full features of Ada.
10. Desire to rapidly bulk migrate large and complex FORTRAN applications over to Ada with no real attention to restructuring to take advantage of the advanced features and modern methodologies of Ada.
11. Use of automated tools to rapidly bulk migrate large and complex FORTRAN applications over to Ada with minimal human intervention. No provision for evolving the application to exploit the advanced features and modern methodologies of Ada.
12. Lack of any deep institutional support for the advanced software engineering and object-oriented methodology features of Ada.
13. Lack of sufficient experience by technical management with the advanced software engineering and object-oriented methodology features of Ada, or with the requirements for staffing a project with emphasis on modern software engineering and object-oriented methodologies.
14. “We don’t have time to do it right.” Ignorance or incompetence on the part of management — or the simple reality that external factors preclude proper scheduling.

The thesis of the author is that besides being a specific reference to coding in Ada as if it were FORTRAN, the term Adatran can also be used as a general-purpose metaphor for the use (or I should say misuse) of any new technology as if it were some existing and less-featured older technology with which the user is much more intimately familiar and experienced. Virtually all of the listed causes of Adatran will generally be relevant to any advanced technology — substituting the two relevant technologies for Ada and FORTRAN.

The C and C++ programming languages are another example — it is (too) easy to quickly migrate C code to a C++ compiler without fully or properly exploiting the full power of object-oriented programming or other C++ features, such as generics, templates, or polymorphism.

Or take your own favorite pair of older and newer programming languages or software systems.

Or database systems, migrating from simpler data modeling metaphors to a database system supporting much more sophisticated data modeling metaphors.

Another example which is a main interest of the author is quantum computing. Trying to simply and literally map a classical computer algorithm to run on a quantum computer is problematic at best. Even if successful, it is unlikely to exploit quantum parallelism, which is the only good reason to move to a quantum computer in the first place.

Adatran as a general concept for all technologies

As mentioned, virtually all of the listed causes of Adatran will generally be relevant to any advanced technology — substituting the two relevant technologies for Ada and FORTRAN, as shown here:

1. Minimal or weak training in the new technology.
2. Training using analogy, showing how features of the existing, older technology can be very easily mapped directly into features of the new technology, but without thinking through whether this is really exploiting the advanced features of the new technology.
3. Insufficient training in the philosophy and benefits of the new and advanced features of the new technology.
4. Insufficient time and staff to become more thoroughly acquainted with the new and advanced features and benefits of the new technology. Raw schedule pressure.
5. Too much attention on features rather than on modern methodology.
6. Insufficient examples of how to upgrade existing metaphors in for the older technology to more appropriate metaphors in the new technology.
7. Individuals are still “thinking in (the mindset of) the old technology” rather than “thinking in (the mindset of) the new technology.” A change of mindset is definitely needed, but difficult to arrange. It takes both commitment and time. And management and social support as well.
8. An explicit goal to use the Adatran approach as a teaching tool, despite its limitations. Sure, it gets more people onboard more rapidly, but at the longer-term cost of not taking advantage of the new and advanced features and benefits of the new technology.
9. Lack of methodical code reviews with explicit technical criteria for proper exploitation of the full features of the new technology.
10. Desire to rapidly bulk migrate large and complex applications over to the new technology with no real attention to restructuring to take advantage of the advanced features and modern methodologies of the new technology.
11. Use of automated tools to rapidly bulk migrate large and complex applications over to the new technology with minimal human intervention. No provision for evolving the application to exploit the advanced features and modern methodologies of the new technology.
12. Lack of any deep institutional support for the advanced methodology and features of the new technology. Including and especially inadequate funding by management, including non-technical management.
13. Lack of sufficient experience by technical management with the advanced methodology features of the new technology, or with the requirements for staffing a project with emphasis on modern methodologies.
14. “We don’t have time to do it right.” Ignorance or incompetence on the part of management — or the simple reality that external factors preclude proper scheduling.

How to avoid Adatran

Basically, simply reverse each of the causes of Adatran:

1. Provide thorough and deep training in the new technology.
2. Refrain from training using analogy — showing how features of the existing, older technology can be very easily mapped directly into features of the new technology. Instead look more broadly how larger portions of the application can be restructured to exploit the advanced features of the new technology, rather than a too-simplistic one-for-one feature mapping.
3. Provide sufficient training in the philosophy and benefits of the new and advanced features of the new technology.
4. Allow sufficient time and staff to become more thoroughly acquainted with the new and advanced features and benefits of the new technology. Make room in the schedule to reduce time and staff pressure.
5. Focus more attention on modern methodology rather than features of the new technology.
6. Develop a comprehensive set of examples of how to migrate existing metaphors in the older technology to more appropriate metaphors in the new technology.
7. Make the commitment and time to getting people to “think in (the mindset of) the new technology.” A change of mindset is definitely needed. Get commitment and time from management and social support as well.
8. An explicit goal to refrain from using the Adatran approach as a teaching tool. Sure, it has the short-term cost of taking longer to get more people onboard, but at the longer-term benefit of taking advantage of the new and advanced features and benefits of the new technology.
9. Methodical code reviews with explicit technical criteria for proper exploitation of the full features of the new technology.
10. Avoid bulk migration of large and complex applications over to the new technology with no real attention to restructuring to take advantage of the advanced features and modern methodologies of the new technology.
11. Avoid use of automated tools to rapidly bulk migrate large and complex applications over to the new technology with minimal human intervention — and without attempting to fully exploit the benefits of the new technology.
12. Achieve deep institutional support for the advanced methodology and features of the new technology. Including and especially adequate funding by management, including non-technical management.
13. Achieve sufficient experience by technical management with the advanced methodology features of the new technology, and with the requirements for staffing a project with emphasis on modern methodologies.
14. Make time to do it right. Train or replace management, technical and non-technical, to adequately schedule project resources for the new technology. Work with external actors to gain sufficient schedule flexibility.

Historical references

It is unknown by this author who first coined the technical term Adatran. Google search sheds no light. There isn’t even a Wikipedia page for it.

The author first became aware of Adatran while attending an Ada conference in Washington, D.C. in the mid-1980’s (1985 or 1986 or so, if my memory serves me.)

A Google search finds the earliest online reference dated 1988 in the proceedings of a NATO technical conference — Software Engineering and Its Application to Avionics. There are a few more references in the early 1990’s.

There is one loose reference to the general concept, but not to the literal term Adatran, from 1986:

• [Ada Joint] Program Office Guide to Ada Edition I
• September 17, 1986
• “Converting Non-Ada Programs into Ada”
• “The transition to Ada raises two problems: finding a way of reusing existing software written in another language, and cutting down the costs of redesigning and reimplementing existing software in Ada. There are no easy solutions to these problems. The desirable solution in some cases could be to create an interface between the existing code and Ada, as discussed in Section 7.1. Another solution, discussed in Section 7.2, is to attempt to convert the original code into Ada. This is a complicated process and in most cases, it will not produce the software engineering benefits associated with Ada.”
• “A translation resulting in a FORTRAN or COBOL program written in Ada syntax should be avoided. Unfortunately, present day technology is incapable of converting an outdated design to an Ada-based design that concurs with current program design methodologies. The reason is that it does not exploit the advanced capabilities of the Ada language and does not provide the software engineering benefits that can be expected from the appropriate use of the Ada language.”
• https://apps.dtic.mil/dtic/tr/fulltext/u2/a183226.pdf

The NATO reference from 1988:

• Software Engineering and its Application to Avionics
• April 1988
• NATO AGARD Conference Proceedings №439
• “So what does one do it one wants (or is required) to use Ada to program embedded systems. Well, mostly, only use the parts of Ada that the 1750A is capable of handling. But then the programmer might as well have used FORTRAN; hence the name AdaTRAN.”
• https://apps.dtic.mil/dtic/tr/fulltext/u2/a203892.pdf

Then in 1990/1991:

• U.S. Department of the Army FY 1990 Small Business Innovative Research Topics — Technology for Reengineering Tactical Software Systems
• 1990 or 1991 (fiscal year 1991)
• “The existence of tools, methods, and techniques for quickly and efficiently reengineering these systems (i.e., producing software engineered versions in Ada) would permit these existing systems to continue to be used, evolved and maintained in a cost engineered version in Ada) would permit these existing systems to continue to be used, evolved and maintained in a cost effective manner. Unfortunately, existing tools and techniques that purport to “reverse engineer” existing software, more often than not produce an Ada version of the Fortran or assembly language code, without reengineering or structuring the software in a software engineering sense. This results in “Adatran” code that has the appearance of Ada, but the structure and problems of Fortran code. The ability to overcome this barrier and to be capable to determining the functional and behavioral characteristics of existing software is essential to the success of quality Software Reengineering CASE Tools.”
• https://www.acq.osd.mil/osbp/sbir/solicitations/sbir19902/army902.pdf

Also in 1991, from NASA:

• An Overview of Object Oriented Design
• April 30, 1991
• “The NASA Goddard Space Flight Center (NASNGSFC) has experimented with Ada and OOD in the Software Engineering Laboratory (SEL) in the last few years. They concluded that Ada needs to be taught with a design methodology; otherwise. the result is “Adatran” code. Ada code written in a Fortran style.”
• https://pdfs.semanticscholar.org/58ff/b318a8314982d9f9bbe4fd7d903868ea228a.pdf

Then in 1992:

• Ada Adoption Handbook: A Program Manager’s Guide Version 2.0
• October 1992
• “Those who already know a structured high-order language like PASCAL should assimilate the new techniques more rapidly. However, beware of teaching by analogy (i.e., by showing a construct in an old language and then demonstrating how to accomplish the same thing in the same way in Ada). This leads to a continuation of the problems of earlier software development generations written in new syntax, e.g., AdaBOL or AdaTRAN. The student is less likely to readily adopt new ways of accomplishing old tasks that are more powerful and more suited to Ada, taking advantage of “new” Ada features such as packages, tasking, exceptions, aggregate assignments, use of Boolean expressions, etc. Students must be taught to think in Ada.”
• https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=11721
• https://resources.sei.cmu.edu/asset_files/TechnicalReport/1992_005_001_16100.pdf

And then in 1993:

• Proceedings of the Eleventh Annual National Conference on Ada Technology
• March 15–18, 1993
• “The most common student in an Ada class is an engineer with experience usually in FORTRAN, whose employer is considering the use of Ada. His/her engineering discipline may vary but for the most part it is applied outside of the computer science field. Typical disciplines are controls, navigation, guidance, or structures. These engineers leave their work assignments for a few weeks to receive Ada training. When they return to their jobs, and only when required, they begin to write in Adatran, Ada that looks exactly like the FORTRAN that they were previously using. The code uses “common blocks*, no generics nor tasks, and is usually contained in one package.
• The fault does not lie with these engineers. The system only provided time for learning a new syntax, not a new software engineering methodology. One of the philosophical goals of Ada is to improve the overall education in software engineering.”
• https://doi.org/10.21236/ada262517
• https://apps.dtic.mil/dtic/tr/fulltext/u2/a262517.pdf

Also in 1993, but referencing the concept but not the literal term:

• A Review of Non-Ada to Ada Conversion
• August 5, 1993
• “The fact that data is maintained in Fortran format throughout the converted system, exemplifies the fact that Automatic Translation results in a converted system of Fortran coded in Ada and does not utilize the software engineering capabilities of Ada.”
• https://www.csiac.org/wp-content/uploads/2016/02/A-Review-of-Non-Ada-to-Ada-Conversion.pdf

An attempt at a definition, as of 1995:

• The Language List — Version 2.4, January 23, 1995
• “downloaded 1/17/01 from ftp://wuarchive.wustl.edu/doc/misc/lang-list.txt”
• “AdaTran — Name given informally to an Ada subset and coding style
• reminiscent of the worst examples of Fortran, incomprehensible and full of
• GOTO’s. The ENCORE Project at GE Corporate Research used this term for the
• output of their Fortran-to-Ada translator. ENCORE (ENvironment for COde
• RE-engineering) was a system for turning AdaTran into readable Ada.”
• http://homepage.divms.uiowa.edu/~fleck/lang-list.txt

And another reference from NASA in 1995:

• Impact of Ada and Object-oriented Design in the Flight Dynamics Division at Goddard Space Flight Center
• March 1995
• “GOESIM [Goals] Deliver first-of-a-kind Ada system on schedule and within budget [Results/Key Lessons Learned] Delivered AdaTRAN on schedule and within budget; code not reusable”
• The decision to use Ada came late on this project. Both FORTRAN and Ada were being considered up until the preliminary design review (PDR), at which time upper management committed to using Ada. This constrained the preliminary design to a FORTRAN-like structured design, which, due to budget and time constraints, was never redesigned after Ada was chosen. Thus the system made little use of Ada features and was coded in what is commonly referred to as AdaTRAN.”
• “To take full advantage of Ada, early commitment to using the language is needed; i.e., before the design phase starts.”
• “It is very difficult to reuse object-oriented parts in a structured design.”
• https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19950022386.pdf

I ended my historical search there. Actually, I did a fair amount of additional searching, but found nothing to add any significant value to the results already shown here.

Definition

I’ll go ahead and put forward my own personal definition…

Adatran is any of these senses:

1. The use of the Ada programming language as if it were the FORTRAN programming language.
2. Coding in the syntax of Ada with the style and semantics of FORTRAN.
3. Ada code written by a FORTRAN programmer.
4. A subset of Ada taught to FORTRAN programmers.
5. Ada code generated by an automated translation of FORTRAN code.
6. Ada code generated by automated translation of any non-Ada programming language.
7. The use of any advanced technology as if it were an older technology with which one is more familiar and experienced.

Wikipedia

As mentioned earlier, there is no Wikipedia page for Adatran. I’d invite any enterprising soul to feel free to excerpt material from this paper, including citations, to create a professional Wiki page for Adatran.

This paper is written as original research and my own opinions, especially my view on using Adatran as a generic concept separate from Ada and FORTRAN in particular, so as such it is not directly suitable as a Wiki page, but a Wiki page could legitimately cite this paper as source for content from this paper and its cited references, especially the historical sources.