{"id":852,"date":"2026-10-18T17:50:00","date_gmt":"2026-10-18T17:50:00","guid":{"rendered":"https:\/\/bestpilotsnow.com\/blog\/?p=852"},"modified":"2026-10-18T17:50:00","modified_gmt":"2026-10-18T17:50:00","slug":"devops-myths-flight-deck","status":"publish","type":"post","link":"https:\/\/bestpilotsnow.com\/blog\/devops-myths-flight-deck\/","title":{"rendered":"Six DevOps Myths Still Circling the Flight Deck"},"content":{"rendered":"

The conversation happened, as these things do, over bad coffee beside a parked trainer. A flight school was modernising its booking system, and the operations manager announced that they would “start DevOps in the spring, once the new platform arrives.” I did not have the heart to tell him he had just mistaken the discipline for a delivery, and his sentence for a purchase order. Six myths survive in aviation software circles the way old wives’ tales survive in any hangar. Here they are, with what the evidence actually says.<\/p>\n

Myth one: you can buy DevOps off the shelf<\/h2>\n

The manager’s version. Buy the platform, run the training video, tick the box. The definition, though, has nothing to do with procurement: DevOps organises software delivery so the people building and the people operating pull to one agenda with common tooling and open feedback, getting changes to users fast, safely, and again and again. It is explicitly not merchandise, not a job title, not a siloed team, not a product. The adoption numbers settle the argument \u2014 a toolchain bought first and rolled out centrally scored 2.40 out of 5, the weakest route studied, while one value stream piloted with an enabling coach reached 4.25. Tools help; tools alone are decoration.<\/p>\n

Myth two: top performers max every metric at once<\/h2>\n

This one sounds like praise and functions like an excuse \u2014 “we can’t be fast AND reliable.” The research describes balance, not perfection. Elite teams pair high deployment frequency with low change failure rates and fast recovery, and the newest measure, rework rate, added in 2024, counts the effort burned redoing work. Even the recovery metric was refined in 2023, narrowing the count to failures the change itself caused, because honest numbers beat flattering ones. Perfection is not the standard; trajectory is.<\/p>\n

Myth three: regulated aviation software cannot move fast<\/h2>\n

The most stubborn myth, and the most disproven. Heavily audited industries adopt these practices successfully, because automated controls satisfy auditors better than meetings do. Least-privilege access. OIDC credentials that live minutes instead of eternal production keys. Expand-and-contract schema migrations, so rolling back never strands your data. Quarterly audits sampling about ten random changes rather than drowning reviewers in everything. A break-glass merge path for the rare true emergency, logged every time. Meanwhile the heavyweight change approval board \u2014 the industry’s favourite comfort blanket \u2014 is associated in the DORA research with worse performance, not better safety. Compliance and DevOps are not enemies; bureaucracy and evidence are.<\/p>\n

Myth four: DevOps demands microservices and Kubernetes<\/h2>\n

A flight school booking system does not need a service mesh, and neither does your dispatch tool. Microservices and Kubernetes are simply not required. What is required is a short, automated path from commit to production with feedback that arrives in minutes. Plenty of unglamorous monoliths ship several times a day and recover faster than their fashionable neighbours. Choose architecture for the problem; choose practices for the delivery. Confusing the two is how purchase orders get written for things nobody operates.<\/p>\n

Myth five: more approvals after an incident make us safer<\/h2>\n

Every operator knows the reflex: something breaks, so a signature is added. It feels like accountability and behaves like sediment. Approvals stack up after each event until shipping anything requires a committee, and the queues quietly raise the odds of the next big-bang release \u2014 which raises the odds of the next incident. The loop is famous and it is vicious. The alternative is a drilled runbook: deployment carries an identifier and an owner; roll back if no irreversible migration has run; otherwise switch it off with a flag, or fix forward where no flag exists; and hold a blameless review inside five working days. One documented failure, a four percent payment-error spike, took about 190 minutes to reverse because nobody had practised. The same failure rehearsed closes in roughly twenty.<\/p>\n

Myth six: transformation is a big-bang programme<\/h2>\n

Ribbon, logo, all-hands, all teams, one quarter. The maturity ladder tells a different story: first siloed working, then automated islands, then integrated stages, then continuous delivery, and at the summit a learning system \u2014 a climb taken in order, one value stream at a time. Even the early wins come with a price, the J-curve: quick improvements, then a dip as automation raises the testing bar. Strong teams agree the acceptable dip duration before they start, exactly as a pilot accepts that the first ten hours of instrument training will feel worse before they feel better.<\/p>\n

What the six myths share<\/h2>\n

Look closely and all six are the same mistake wearing different jackets: the belief that delivery performance is a procurement or policy problem rather than a systems-and-habits problem. Buy the tool, mandate the metric, pile on the approvals, launch the programme \u2014 each move tries to purchase an outcome that only a redesigned path can produce. That is why the myths feel true to reasonable people. They all worked somewhere, once, for a team that no longer remembers the aftermath.<\/p>\n

What to believe instead<\/h2>\n

Swap the six myths for five boring truths.<\/p>\n