What Is Adatran (or AdaTRAN or 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.

Adatran as a general concept for all technologies

  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

  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

  • [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
  • 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
  • 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
  • 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

Definition

  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

--

--

--

Freelance Consultant

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

What programming language has the happiest developers?

Billyboss (192.168.55.61) (GTW/Very Hard)

A Systematic Approach to Dynamic Programming

The Developers’ Burn Out Is Real. Here is how you can prevent it.

Getting started with Docker

How to export >100x faster .csv files from R for big data

The Top 10 Mechanical Engineering Positions Available to Indian Graduates

Copy API data to Azure SQL Database using Azure Data Factory

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jack Krupansky

Jack Krupansky

Freelance Consultant

More from Medium

ResourceScalingForSimulatingQuantumDynamicsOfSpinChains

image.png

Happy Vibrant Dream about Unusual Chain Of 118 Atoms.

Dreaming About Elements of Periodic Table

Elon Musk | Twitter / Catgirl / Tesla | Stock