4 lessons for high-quality software from a surprising place

High-risk industries have regulatory compliance for a reason. While regulatory requirements might feel like a painful or tedious process, they build guardrails that save time and money in the long run.

Because no one person should be in a position to cause an aircraft component to fail.

Prior to joining Test Double in 2023, I had spent nearly the entirety of my professional career working in regulated software industries. With a decade of experience in aerospace, I learned how to implement the stories and code that made up a product while always staying within the scope of the regulations.

As I’ve moved away from regulated software industries and into DevOps consulting, I keep finding myself falling back on some of the productive patterns I developed throughout my career to help provide higher quality software and more sustainable solutions without significantly impacting time to delivery.

Here are the best practices I learned as a developer in a highly regulated industry — and they’re things that we all could do better as developers to genuinely improve code quality. In turn, they would help our clients’ bottom line by avoiding rewrites, decreasing bugs and defects that impact customers, and minimizing security risks.

With the right processes and systems in place, you won’t get surprised or end up in failure states. These processes and systems enable you to create high-quality software that’s stable, scalable and trustworthy.

Formalize the deployment process

At the backbone of any regulated software industry is an emphasis on process over people. This is crucial in environments like aviation, where the safety of passengers and crew relies on robust procedures. Documenting a formalized process helps with everything from risk mitigation and early detection of issues to consistency, scalability and efficiency.

With good process, I’ve found a lot of the failures assessed to individuals or teams can be addressed while skipping over the “at fault” portion of the retrospective. The focus on process can also help drive notification of risk and difficulties earlier in the schedule as errors and process deviations can become notifications that something isn’t working as expected.

Finally, when you formalize the deployment process, you create turn-key solutions because you identify and clearly spell out step-by-step what has to be done for a successful deployment. It makes it simple for any other developer to step in and continue deployments without interruption.

Retrospective documents are part of the deliverable

In the rapid-fire development space, it can be easy to ship code and move on to what’s next. However, in highly regulated industries, the work doesn’t end when code is shipped. There are a collection of other deliverables as part of the final product in regulated software.

In regulated industries, adherence to compliance standards and regulations is non-negotiable. Forced retrospectives, through required documentation, ensure that teams document their processes, decisions, and actions comprehensively, facilitating compliance with regulatory requirements.

Many of these take the form of supporting documents, such as verification and validation reports, requirements capture, requirement mapping, statement coverage review, and documentation of known issues. All of these artifacts serve the purpose of providing clarity to an outside party on how the software was developed and the deliverables were created. Through the creation and revision of these documents every deliverable has the opportunity to identify areas for improvement in future deliverables.

Additionally, as a consultant, these retrospective practices are hugely helpful. They provide an excellent starting point when preparing to hand off work to a client at the conclusion of an assignment.

The regular creation and revision of retrospective documents is extremely helpful in order to deliver a great consulting experience – from establishing a continuous improvement culture to knowledge sharing.

Reduce tech debt with every major delivery

One of the biggest frustrations as a developer in a highly regulated industry is a requirement around minimizing tech debt — but it’s also one of the most important practices.

The FAA certification process has a built-in correction mechanism for handling tech debt. The process requires resolution of a quantity of technical debt as part of each major delivery. In addition to the requirement to report tech debt as part of each delivery, each iteration of the application must resolve a percentage of outstanding technical debt.

This also prevents deliveries that are injecting large quantities of technical debt into the certified applications as they will come due on the next delivery. The transparency around tech debt forces everyone to address the issues promptly and forces developers to fix things they might not want to fix. Adopting the practice of minimizing tech debt with each major delivery limits new technical debt and prioritizes the highest risk technical debt.

By actively managing and resolving technical debt with each major delivery, developers satisfy regulatory compliance – and also set up the business for long-term code quality and cost savings.

Standardization improves speed to value

During my time in Aerospace I worked in seven different roles across four different teams. I shifted from development, to test, to hardware/software integration, to certification leadership and document creation across both government and commercial clients.

In each case, I could join a new team and contribute within a couple days. That was because at the highest level there was a company-wide “Software Development Process.”

Standardization required by regulatory compliance offers consistency and predictability – which leads to efficient workflows, more accurate estimates, scalability and reduced risk. This enabled me to move between teams and roles, languages and codebases very quickly because there was always a common process at the backbone of all activity.

Projects delivered in multiple langues, operating systems, and hardware configurations all had a common throughline, which allowed me to contribute immediately to all teams. Lessons learned in one area could be applied to other areas and cross team communication and process sharing were encouraged and simple because we shared the same fundamental structure.

There are no shortcuts to doing a good job

My experience in the aerospace industry taught me regulatory compliance is about far more than regulatory mandates. It establishes a foundation for success for high-quality code and minimized risk that save time and money in the long run.