Connect mathematics and software with reliable operations

Mathematicians and analysts model trajectories, structures, signals and uncertainty. A correct manipulation of equations can still answer the wrong question if the initial conditions, units or physical assumptions are wrong. Teams therefore need to connect a calculation with the actual mission and the meaning of each input.

Katherine Johnson’s trajectory work included checking calculations for John Glenn’s 1962 orbital flight. Dorothy Vaughan led the segregated West Area Computing group at NACA and developed programming expertise as computing changed. Their histories include both technical contributions and the institutional barriers surrounding that work.

Margaret Hamilton led the MIT Instrumentation Laboratory’s Software Engineering Division during Apollo. Her team’s work connected guidance software, testing and reliable behavior in a demanding flight system. It should be credited as team leadership and engineering rather than reduced to a story that one person wrote every line of the mission.

Software engineers specify interfaces, handle unexpected inputs and test how components behave together. A program that produces the right result for one ideal example may still fail at a boundary condition, after a delayed message or when a sensor reports invalid data.

Check the meaning as well as the number

For a fictional example, one program expects time in seconds while another supplies milliseconds. A numerical value can be valid in both formats yet have different meanings. Tests need to verify the interface contract — open definition, not just whether a number was received.

Independent calculations, representative simulations, code review and integrated tests catch different classes of error. They do not prove that every possible failure has been eliminated, but they provide evidence about specified behavior. Preserve assumptions and configuration so that a later investigator can reconstruct which software and data produced a command or result.