What Manpowered Flight Teaches Us About the Benefits of DevOps

Confused by the title? Well, let’s start with DevOps. If you’re reading this blog, there’s a good chance you’ve heard the term, but its meaning seems to depend on how companies that dabble in DevOps spin the definition.

A simple Google search defines DevOps as “a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals, while automating the process of software delivery and infrastructure changes.”

In plain language, DevOps essentially brings the culture and mentality of agile software development to the infrastructure side of the house – creating a sort of “blessed union” of development and operations (hence, the abbreviation by which it is known).

This happy marriage is designed to produce iterative development and deployment cycles that are more frequent, much safer, and that allow the team to achieve their goals quicker. More software deployments into production means a quicker path to attaining business goals.

For a real world example, let’s examine the story behind the first time a human was able to power an aircraft. Our story begins in England in 1959, when a British industrialist, Henry Kremer, established the Kremer Prize. Kremer said he would award £50,000 to any group who could build and fly a human-powered aircraft that could navigate a one-mile figure eight course. Over the next 17 years, 50 teams accepted the challenge — and all 50 failed. All invested months of planning and untold resources into the effort, only to watch their efforts fail to achieve the goal. Many of these groups were unable to fund a second attempt.

In the early 1970s, Dr. Paul MacCready (not to be confused with the former Beatle with a similar-sounding name) took a fresh look at the Kremer Prize. He reviewed the 50 failures and pronounced, “The problem is that we don’t understand the problem.”

By this, he meant that the challenge of building a manpowered aircraft was so laden with details, that it was impossible to consider every potential pitfall that could cause the project to fail. (Those of you who have undertaken a large IT migration or large software deployment project are nodding their heads in agreement right now. It’s impossible to sit in a room with your team and whiteboard out everything that needs to be considered, addressed and resolved.)

The solution Dr. MacCready arrived at was simple — and dare I say, very “DevOps-ish.” He designed and built an aircraft that was made to be easily rebuilt after crashes. It flew only a few feet off the ground, and at a very slow speed. But, with every crash, he learned something integral to improving the process; his modular design meant that he could rebuild, incorporate an improvement and fly again. He actually did this try-crash-rebuild cycle 222 times.

However, on the 223rd flight – just six months into the process — he successfully completed the challenge and collected the Kremer Prize. Dr. MacCready’s Gossamer Albatross succeeded where others failed because his “DevOps” approach to the challenge allowed him to iterate, and re-iterate, until he achieved flight.

DevOps – like Dr. MacCready’s glider — is about evolving through iteration. It’s not so much an approach grounded in technology, as it is an exercise in embracing the concept of try-fail-try again.

Cloud computing today offers IT organizations the opportunity to take flight, in much the same way as Dr. MacCready. By “spinning up” test environments that are designed to flush out the inherent defects, it’s a no-brainer to consider this DevOps approach – many iterations, embrace failing quickly, learn from the failures, improve and try again. Happy flying.