Pilots don’t want to crash. And neither do technical teams.
Okay. Granted, developing software isn’t the same as piloting a plane. If you mess up a software release, you’ll get some angry customers and may lose some in the process, but... usually no one dies. Piloting, on the other hand… well, the consequences are pretty dire if something goes wrong.
But there are some things software developers can learn from pilots.
Pilots use the adage, “Fly before you fly.” Under this philosophy, they emphasize the importance of planning a flight as much as possible before actually taking flight. Many of the techniques that pilots use to plan a flight, maintain a flight and land safely, can be applied to software development.
Planning for a safe flight and landing
All pilots go through a series of ceremonies before takeoff. Whether they’re doing pattern work or flying cross-country, all pilots perform the same techniques.
Before even considering a flight, there is significant planning. It may not seem like much to the naked eye, but believe me, there is plenty of planning.
Here are some of the things that a pilot does before taking flight:
- Review flight books. Pilots look at the last time the plane had its inspections, as well as the maintenance records for the aircraft.
- Account for weather. A pilot will always, always, always look at weather. This is because the weather will differ depending on where they are; it might be sunny where they start, raining and windy en route to the destination and cloudy when they land.
- Health check-up. Pilots make sure that they and other co-pilots are both mentally and physically well before taking flight.
- Pre-flight inspection. Pilots conduct pre-flight inspections inside and outside the entire aircraft (including the wings, tires and tubing) to note any issues before taking flight.
- File the flight plan. Pilots file flight plans, including a plan for diversions, to communicate their intended route. Sometimes, where one originally intends to land isn’t the best place to land. It’s best to plan for contingencies.
- Obtain pre-flight briefing for TFRs (Temporary Flight Restrictions), NOTAMs (Notice to Airmen). Sometimes a planned route may have some TFRs, like a presidential visit or a sporting event, so pilots need to know if they're allowed to travel to the intended destination. Additionally, there may be NOTAMs informing pilots of closed runways, disabled landing lights, etc. It’s important to know this ahead of time before they're greeted with a couple of F-15s waving at them to follow.
- Provide pre-flight brief to passengers. People who travel with the pilot will like to know what they can and cannot do while inside a plane. So, a pilot will communicate to their passengers what they're doing, what they expect from passengers and where the barf bags are located.
- Conduct pre-flight instrument check. Radios, gauges, etc. all have to be checked on the ground before taking flight. Because once a pilot gets up there, they can’t pull over and check it out. They may have a nifty GPS, but what if that goes out in flight? Then what will happen? They still have to fly the plane. Electrical systems go out.
- Review aircraft performance. Since all aircrafts are different and behave differently in various conditions, pilots review characteristics of the aircraft they are flying. This includes things like the stall speed, rotation speed (speed at which they begin takeoff) and glide speed.
A pretty hefty list, isn’t it? And the pilot isn’t done yet!
During a flight, the pilot continues to:
- Check the weather
- Verify the health of pilot and passengers
- Monitor the ongoing operation of the plan and instrumentation
- Verify TFRs and NOTAMs
- Stay in constant communication with passengers
- Monitor flight time to estimate fuel burn
Notice a pattern? (No pun intended.)
Just as a pilot needs to plan ahead and constantly review the status of the situation, so too does a team of software engineers need to plan ahead and check the project's status.
Getting a team to work well together to achieve a collective goal is not an easy thing to do, but it can be done. To keep a group of smart people energized and motivated to complete a project or a goal requires diligence to careful planning and execution, as well as patience to overreaction.
Planning for a safe product launch and release
With software development (especially in an Agile environment), much of what we do relates to what pilots do when approaching a new flight.
As we plan for a software release, we require a significant amount of planning. This includes:
- Reviewing backlog items. Just as pilots review the documents and flight plans for a particular flight, the team collectively reviews similar documents such as design specifications, user stories, etc.
- Forecast planning. Pilots review weather, while software development teams review product roadmaps. When you include forecasting in your plan, you can identify larger scale initiatives. In software, we forecast for scalability and performance.
- Resource planning. Like a pilot who checks his own capabilities, a team's health and capabilities must also be frequently checked for the successful completion of a release. Do you have the correct group of skill-sets on the team to achieve the objective? Is there enough fuel in the tanks?
- Project/Release planning. Pilots plan their route. They review the most direct path to the destination. In software development, we do that by maintaining our focus to MVP (Minimal Viable Product). Sure, we will pivot, but focusing on the MVP allows us to remain clear on what matters most. In either case, it’s all about arriving safely.
- Contingency planning. In piloting, it's important to look for alternate airports or destinations if they're unable to land safely at the original destination. In software development, we do that too. We sometimes plan for the ‘happy path,’ but we also need a contingency plan. We need to account for what happens if a data conversion doesn’t complete. What if an outage occurs? What if our new platform architecture isn’t able to scale? All of these decisions are crucial to reducing impact to the customer and providing a positive experience. Sometimes landing safely – but close to our original destination – is much, much better than crash landing at our intended destination.
Embracing the Checklist
A pilot isn’t expected to remember everything. Sure, a high percentage of their training is performing engine-outs to promote a muscle-memory reflex to react in a way that's consistent, safe and not emotional. But pilots also use checklists. Lots and lots of checklists.
They use checklists for pre-flight inspections. They use checklists for flight planning. They use checklists for emergencies. They use checklists for landing. Pilots depend on checklists. Period.
Because it’s best to follow a set of proven, objective procedures rather than risk forgetting a step at a crucial time. Checklists prove to be an effective tool to guide the pilot to successful and safe flights. And for software development, we can use a similar tool to provide a safe landing as well.
With Agile, we kinda use checklists – although we don’t call them that. For example, we use a format for “Start, Stop, Continue and Kudos” during retros. We use a format for sprint planning to arrange and plan our sprints. We employ a set of tasks to follow when we roll out a new release.
Software development teams could benefit from utilizing checklists to take steps to ensure the integrity and quality of the release. Sure, Continuous Integration/Continuous Delivery is awesome to maintain consistency, but much of a release isn’t just about the assets and the code. Data will always come back to bite you if you aren’t diligent with managing this step.
For piloting, it’s all about arriving safely.
In software development, we do everything we can to ensure the customer gets a remarkable experience and the intended outcome. With proper planning, monitoring and checklists, we eliminate the unknowns to ensure that the team arrives safely at their intended destination: a rock-solid software release.