In my professional life, I develop and manage software projects.  In my personal life, I am a recreational private pilot.  Becoming a pilot was challenging but extremely fun, and continues to be a great learning experience.  I’ve found that the process of becoming a pilot has taught me a lot of useful things about how to manage software projects.

When you are taking flight lessons, you need to learn many different things, in a broad range of topics.  You learn some academic stuff (like aerodynamics and meteorology), some hands-on stuff (like how to actually control an airplane) and a bunch of details (like airspace regulations, and other rules and numbers you just need to remember).  But one of the most important lessons you are taught is problem solving and resource management.  In other words, all that knowledge you gained during your lessons is no good if you are too stressed or overwhelmed to keep control of the airplane and get it to its destination safely.

Here’s four key points I’ve taken away from my flight lessons and how they can be applied to software projects:

1. Use checklists. The human brain can only hold a small number of things in short term memory at any one time (somewhere around 7).  Pilots use checklists to avoid relying on the memory limitations imposed by human anatomy.  They are used at just about every stage of flight, from approaching a plane for the first time, until it’s parked and tied down at the end of the flight. Forgetting one small but critical item (like neglecting to release a handbrake or setting the fuel mixture to the wrong setting) can have some very serious consequences.  By regularly using a checklist, you ensure you do the same things every single time and in the same order.  This idea is useful for many other areas (in fact, a whole book has been written on the subject).  Deploying a server, make a list.  Testing a release, make a list.  Need to fix bugs and track which ones you have fixed already, make a list.   And the great thing about software development is that you can use scripts to automate your lists.  What could be better than typing in a command like “deploy_server” and having all the items on your list execute the same way every time.  It sounds simple, but how many people do you know that do something repeatedly, but manually, and from memory.
2. Have a flight plan and stay focused. Before take-off, pilots make a flight plan – sometimes on paper or via software, and sometimes in their head (if they are only flying around the airport for some practice).  The plan includes a goal for the flight, a destination, some alternates in case the first plan doesn’t work out, and a personal assessment of whether you are up for the flight.  If you have a lot on your mind, are feeling distracted, sick, or otherwise not ready to stay focused, then you are trained to not take off in the first place.  Once you take off, the only certainty is that you will be coming back down at some point – hopefully on a runway.  The same is true of software projects – once you “take off”, are you committed to seeing the project through?  Are you ready to stay focused on the primary goal of the project?  Do you have alternates when the primary plan needs to change mid-course? Do you even know what that goal is?  Does everyone on the team know what it is and do they agree to it?  If you paused when answering any of these questions, maybe you need to revisit your flight plan before you take off.
3. Aviate, Navigate, Communicate. When flying a plane, your most important job is to, well, fly the plane.  It won’t do much good to know where you are and tell someone about it if you crash in the process (unless you care more about them finding your wreck than you do about walking away from it).  FAA crash reports are filled with people who crash after losing control because they were fiddling with a GPS or worrying about what to say to air traffic control.  Those three words remind you of the order in which you should focus your attention: only after ensuring the plane is under control should you worry about navigating, and only after that should you worry about talking to ATC.  In software projects, however, I think you need to go in the opposite direction: Communicate, Goals, Code.  Coding does you no good if you don’t know why you are doing it (the goals),  and having goals is no good if everyone on your team (and your customers) doesn’t know what they are.
4. Use check points.  Whether using GPS or compass, maps, and a clock, before setting out on a flight, pilots mark down prominent points along their routes (a river crossing, a large town) and the approximate time into their flight they expect to pass them (based on winds and estimated airspeed).  Once airborne, the pilot ensures that these check points are passed at about the right times.  If not, you are either off-course or moving slower than expected (or both).  Either scenario is bad, since unexpected fuel starvation in an airplane is a very bad thing (which unfortunately is also common in FAA crash reports).  The same idea applies to software projects, where you should have regular check points to be sure progress is moving as planned.  Software methodologies like Scrum and Agile have iteration meetings every few weeks where you can adjust course as needed.  Projects get to be one year late one day a time, and while having these regular check points won’t necessarily make you go any faster, it will let you make more informed decisions.

One of the unique things about being a pilot is that once in the air, you are keenly aware that your life and the life of everyone in the plane with you is in your hands alone (the same is true of driving a car of course, although you have the luxury of pulling over if you suddenly decide you aren’t fit to drive anymore).  Most software projects don’t have that same level of importance, but they can still benefit from the all tricks that aviation has come up over the years for keeping that key take off/landing ratio = 1.