Four engineers maintain the scheduling and student-tracking software for a flight academy we will not name. One Tuesday in March, the Monday-generated instructor rota failed to publish, and a fix that should have taken twenty minutes consumed the day. The bug was ordinary. What surrounded it was not: a nineteen-minute build, a review request that sat unread through lunch, a release window that had already closed. Nobody in this story was lazy. All of them were waiting \u2014 and waiting, they eventually learned, is exactly what DevExOps exists to measure and remove.<\/p>\n
The four of them now describe that Tuesday as the moment they stopped treating developer experience as weather and started treating it as something they could audit.<\/p>\n
The framing is simpler than the name suggests. Aviation software, like aviation itself, rarely fails at the exciting moments; it fails in the waiting between them. The DevExOps tradition holds that the measurable damage lives in the pauses \u2014 before the build finishes, before a reviewer answers, before the pipeline opens. So an audit does not grade the code. It times the pauses, asks the people who stood in them, and checks that whoever owns each pause knows they own it. The xOps School DevExOps entry<\/a> sets out the loop in full; what follows is the field version the four engineers now run every quarter.<\/p>\n Timing matters as much as technique. The checklist earns its keep in three situations: several teams share one toolchain and nobody can say whose week it ruins; a significant investment such as a build farm or a migration needs a before-number to justify itself; or complaints about the same tooling flatly contradict one another and the person refereeing has run out of memory. Other conditions argue for patience. A group small enough for honest retrospectives already does this work around the table. A programme with no decision-maker behind it produces lovely charts and zero changes. And where trust has been worn thin, the opening move is not a questionnaire but one long-demanded repair, released to argue on the programme’s behalf by improving in public.<\/p>\n The first pass found three things, none of them exotic. The nineteen-minute build spent most of its time rebuilding things it had already been told were unchanged, which a caching fix reduced to four. The queue had a genuine rush hour at eleven, when every developer’s morning push arrived together, which staggering start times mostly dissolved. And the review wait, it turned out, was not reluctance but routing: requests went to whoever wrote the original code, who was usually the busiest person on the team. A rotation rule fixed that without a single difficult conversation. The onboarding re-run, meanwhile, exposed a setup document last updated when the academy ran two aircraft; a new engineer now merges a first change inside a week, and the document gets corrected every time somebody stumbles on it.<\/p>\n The rota bug itself? It had been reported in the survey months earlier, worded as “I stop trusting the tooling on Mondays” and filed under feelings rather than faults. That is the quiet argument for running both instruments \u2014 the survey hears what the logs cannot, and the logs prove what the survey suspects. The academy’s own engineering reading list had touched this before; a piece on AI for aircraft engine health monitoring<\/a> makes the companion point that engines are flown hard and monitored harder, while the humans maintaining the software were monitored not at all.<\/p>\n Visitors to this blog come mostly for aircraft, and the software side can look like a different planet. It is not. The habits transfer almost word for word.<\/p>\n Teams raised on operations tooling sometimes ask whether this is just monitoring with a new sticker. The overlap is real but partial. Reliability engineering contributed the habit of thresholds and honest instruments, and a good introduction to those habits \u2014 the practical SRE skills guide on this very blog<\/a> \u2014 is a sensible pre-read for anyone about to run their first audit. The AIOps world adds pattern-finding across noisy signals, described accessibly in a piece on how AIOps makes IT operations smarter and more reliable<\/a>. What DevExOps adds to both is a rule the ops world learned slowly: the numbers describe the system, not the people inside it, and the moment they start grading individuals they stop being trusted, which makes them useless.<\/p>\n The four engineers still talk about that Tuesday in March, usually on Mondays, which now run quietly. The audit costs them about a day per quarter, a figure they checked first, the way they now check everything they are told. In return they get builds that answer in minutes, reviews that answer in hours, a rota that publishes itself, and \u2014 the part none of them predicted \u2014 arguments that end instead of recurring. Aviation built its safety record on the refusal to leave small failures unexamined; the software that supports it deserves the same courtesy, and so do the people writing it. None of the four would call themselves process people. They would say, more or less, that they finally started filing the paperwork the same way pilots do \u2014 not because forms are fun, but because the forms are how nobody has to guess.<\/p>\n","protected":false},"excerpt":{"rendered":" How a small flight-academy software team turned developer experience into a quarterly audit: eight checks, one owner each, and calmer Mondays.<\/p>\n","protected":false},"author":5,"featured_media":674,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[490],"tags":[],"class_list":["post-673","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aviation-technology"],"_links":{"self":[{"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/posts\/673","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/comments?post=673"}],"version-history":[{"count":1,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/posts\/673\/revisions"}],"predecessor-version":[{"id":685,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/posts\/673\/revisions\/685"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/media\/674"}],"wp:attachment":[{"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/media?parent=673"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/categories?post=673"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aiaviationacademy.com\/blog\/wp-json\/wp\/v2\/tags?post=673"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Eight-Point DevExOps Audit, as Actually Practised<\/h2>\n
\n
When to Run the Audit at All<\/h2>\n
What the Audit Caught at the Academy<\/h2>\n
Borrowing from the Ops World Without Losing the Plot<\/h2>\n