of the team continues to be productive, checking in code with no waiting. So a mistake that might not have been detected until takeoff is now found before anyone boards the plane. What would have been hours of delay, now can be isolated and fixed without impacting all the passengers as well as the other planes waiting to take-off.
So how does it really work? We have several customers that put pre-flight builds into practice every day. We have one customer who has seen a 90 percent reduction in broken builds in just a couple of months. And it's worth noting that the remaining 10 percent of broken builds were due to developers who were circumventing the pre-flight build and continuous integration methodology.
The result of testing early and often is that you discover problems in the pre-flight stage versus "mid air" and you get faster feedback, and end up with a cleaner code base. One plane goes back to the terminal but 20 others take off in the meantime. In agile development, you get working software and can release any time because you are hitting your milestones. Your demos are ready to roll; QA is testing the right version and can run a clean test. And, as we all know, it costs a few dollars to catch bugs early, rather than hundreds or thousands when they reach the customer.
Continuous integration is great, but it only tells you there's a problem after it's too late to prevent the downstream damage of that problem - high-performing development teams have incorporated pre-flight build and test to gain agility and focus on the code, not the infrastructure.