Software Development, Control, Test & Management

The latest software issues such as Boeing's CST 100 Starliner and their 737 MAX are just two examples out of multiple examples of poor software control, test and management. However, to be fair, every major defense contractor in the industry is dealing with the same issue. Over my long career, I've seen more and more projects held up at the end for software. So, why do we keep missing the boat in this technical discipline?

I will draw from my limited experience in working closely with software engineers at multiple companies commercial and defense as well as my management experience as an operations manager, responsible for all of operations including hardware and software development.

So, let's get rid of the usual suspects since they only go to clouding the core issues. It's not the fault of the software engineers. Software codes understand how to code inputs and outputs, they do not understand launch vehicle stage separation and timing, nor how a attitude control system is suppose to work, in case of the Starliner software problem. Blaming the software team is not solution because they are not the root cause.

Coder do not understand flight dynamics and flight control nor aerodynamics as in the 737 MAX software flight control issues. Blaming the software coders is pointless. A new engine control unit (ECU) which fails engine tests is not the fault of the software team because they never received a requirements document to write the code to begin with, as was the case on another project I worked at another large aerospace company. So, to keep me out of trouble and getting sued for focusing on one or two companies, let's just use the terms "project," or "product."

Furthermore, we can't blame the lack of standards or specifications with respect to developing, controlling and managing software revisions, changes, test and certification. These standards and guidelines exist, and, they are pretty good, when they are followed and the right level of control is applied at the right stage of the project and type of product.

In engineering, we speak of "laser focus," when addressing technical challenges. Let me state that code writing and testing is the feild that requires the greatest of Laser Focus we can accomplish as human beings. Not all engineers can be code writers, nor want to be. However, if you are a coder and code tester, my hat and admiration goes to your abilities. In fact, the laser focus needed to be a good code writer and be able to wright 100-200 hundred lines of code in a day, drives the personality trait that is required to do the job well, but is often frowned on. Even engineers from other disciplines like Electrical, Mechanical, Manufacturing or even Physics or Math, will be frustrated with the communication challenge needed in conveying the needs of these disciplines and helping the coder incorporate those needs into the software.

Also, I don't want to sell coders and software engineers short. I have run into a few that have an excellent sense of mechanical, electrical systems and can actually see how things fit together at a 15,000 foot level. They still don't appreciate, like say power sense, control and flow resistance curve needed to control the temperature of that ECU. The ME would need to provide that curve or table list of setting.

to be continued......