After being an avid Formula 1 fan since 1990 and a software developer since a couple of years later, I’ve noticed there are a few things in Formula 1 that can be applied to software development. Some of these lessons apply directly to developers, others to development teams, and some to organisations that employ developers.
# It’s Both a Marathon and a Sprint
One similarity I’ve noticed is that both Formula 1 and software development are both marathons with sprints that occur throughout.
In Formula 1 there are (depending on season) around 20 race weekends that go to making up the championship. The championship is the marathon. In software development the marathon is the entire life of the software that is being developed.
The marathon of the Formula 1 championship can be broken down into shorter elements that occur a number of times; these would be the race events. In software development, these are the equivalent of releases.
Potentially each of these could then be broken down further (at the risk of creating some terminology confusion). In Formula 1 the race events are broken down into sessions (practice 1, practice 2, practice 3, qualifying and the race). Using Scrum terminology, these would be Sprints in the world of software development.
So, what can we learn from these similarities?
In Formula 1, there are celebrations for both the overall championship and for winning a race weekend, teams also take pride in their performance in the individual sessions of the race weekend, but generally the celebrations are internal to the team and more subdued. In software development we should celebrate the product. Every release is the cause for celebration. It may not be perfect, but I have never heard a Formula 1 team or driver claim they have had a perfect weekend either. At the completion of each Scrum Sprint (or the equivalent in the project management methodology used by your team) development teams should celebrate their achievements, but in a more subdued way. I haven’t covered a celebration in software development that is equivalent to the championship celebrations in Formula 1, that’s partly because software products have a very long life span and Formula 1 is based on seasons, but there are some championship level celebrations that can be found in software development. When a major component or upgrade is completed this is worthy of a significant celebration.
As well as celebrating achievements, software developers can also learn about sustainable performance and taking a break after a significant investment of energy. The Formula 1 race calendar has occurrences of back-to-back race weekends, but these are almost always followed by a break, additionally, drivers maintain schedules that allow them to recover from every race. In software development we need to be more conscious of our ability to perform in a sustained way. If we have to expend significant effort to meet a deadline or in the final stages of a release, we must allow time for individuals and the team to recover before calling on their peak performance again.
# Practice
During each Formula 1 event there are 3 practice sessions prior to the two sessions that are of significance for the event. In some situations, the performance in these sessions can have a bearing on the outcome of the race event (for example a cancelled qualifying session can mean the grid is formed by the results from practice sessions). Additional to these events, drivers and teams spend many hours practicing in a simulated environment (c computerised simulator in the case of drivers and mock pit-stops in the case of the team). In software development we must constantly strive to improve our ability to deliver solutions and to keep up with technological change.
Software developers tend to be adept at keeping up with technological change; this is partly due to knowledge sharing (which I will cover later) but is also because of our inquisitive nature and desire to improve. We spend a significant amount of time staying abreast of technology outside of work, and many developers maintain side projects to constantly improve their performance.
Unfortunately, many companies that employ software developers don’t see the benefits of allowing their staff to practice and experiment, nearly all tasks are directly linked to a required output. In some organisations time is provided to practice, experiment and learn, and these organisations tend to produce higher quality products and take advantage of newer technologies more rapidly.
# Knowledge Sharing
One aspect that software developers do better than Formula 1 is knowledge sharing. This is partly due to the competitive nature of Formula 1. In Formula 1, knowledge sharing with a team is vitally important, especially if one of the cars has been unable to complete a practice session; however, knowledge sharing between teams is kept minimal due to the competitive nature of sport. In software development we seem to be really good at sharing knowledge externally through meetup groups, forum sites and even special interest online chat rooms. We are less adept at sharing information within a team. This can come from egos that want to hoard information, from distributed teams that don’t have the opportunity to communicate, or from company policies that value an individual’s contribution above the output of a team.
# Quickly recovering from mistakes
In Formula 1, drivers are trained to learn from their mistakes and move forward. I have heard this is made easier by the fact every time they are on the track they are too busy trying not to die to remember the mistake they made on the previous lap, but I think there is a certain amount of psychological training that enables this to occur. In software development we rapidly move on from some mistakes and refuse to learn from others.
When a software developer receives a bug report this is the equivalent to a small mistake on a Formula 1 circuit that costs the driver some lap time. As software developers we usually fix the issue and move on rapidly, not dwelling of the issue.
Where software developers aren’t as good is when a significant mistake is made, or an architectural decision was sub-optimal. In Formula 1 terms a major mistake would result in the car being unable to continue in the session, in software development it could involve an outage that prevents the use of the software. A Formula 1 driver will rapidly inform the team what has happened, take appropriate action to resolve the problem (return to the pits, exit the car to safety, or find a safe place to leave the car), they will then return to the team to debrief; the mistake will result in changes to the way the driver or team operates, but they do not dwell on the issue unless it becomes a recurring pattern. In software development very few organisations are able to follow a similar process. The times I have seen outages occur it is rare for an announcement of the outage to be made prior to any work beginning on fixing the issue, a significant outage often results in developers and/or other staff experiencing a level of panic, and rarely have I experienced a debrief immediately after the incident (it is often days later if at all).
As software developers we need to improve our communication, our immediate response and how we learn from incidents. We also need to improve our ability to move on from an incident and not let it impact our future work in a negative way.
# Admitting fault
Software development teams, when compared to a Formula 1 team, are very poor at admitting fault. I have seen countless cases where the blame for an incident is deflected to other teams, other individuals, company policies or external factors. In Formula 1, the cause of fault very quickly admits to the problem, from a driver to a mechanic, to an engine supplier, fault is quickly admitted, then investigations into the root cause are undertaken. This enables the team to rapidly identify the root cause and ensure it doesn’t happen again, learning from the issue in the shortest time possible.
If software developers are given an environment of psychological safety they will be more likely to admit to mistakes and errors and actions can be identified that will prevent the same issue from occurring again in future.
# It’s a Team Sport
Both Formula 1 and software development are team sports. Casual Formula 1 observers may not realise the size of the teams behind a single car on the track and may assign much of the credit to the individual driver, but without the mechanics, the team back at headquarters and a raft of other roles in the team the drivers would not be able to compete. Software development is very similar; many companies and managers view a software development team as a group of individual contributors, but in reality, the ability for the team to interact and work as one is what will wake them a success.
In software development we need to recognise the importance of working as a team, achieving goals as a team and ensuring the team is always working toward a common goal. In the majority of companies I’ve worked with a form of Scrum has been implemented (not true Scrum, but a derivative of it); one thing that has been common within these companies is that the Sprint goals have been defined based on one or two individuals expected achievements and the tasks for other team members have not been aligned to these goals. To equate this back to Formula 1, it would be like a team working on the speed of a pitstop and the handling of the car, with a team goal of improving pitstop speed because one individual is expected to focus on this while the rest of the team is working on the handling. If a team is aiming to improve pitstop speed, then all team members should be working toward that goal.
Companies can learn from Formula 1 in terms of acknowledging teams over individual contributors. In Formula 1 there is no award for the fastest wheel change by an individual, but there is a lot of pride taken in the fastest pitstop. When a pitstop is abnormally slow, all team members rally around the individual who had an issue and work to improve it for the next pitstop, they celebrate as a team and commiserate as a team.
# Large Distributed Teams
Many software development teams are geographically diverse, and a company will often have multiple discrete development teams.
A casual Formula 1 observer may not see the distributed nature of the Formula 1 team, but they are even more geographically diverse. In Formula 1 the driver is disconnected from the team for much of an event as they are in a car driving around the track while the mechanics and some central staff are in the pit area; there is then a team of specialists that are located in the pit paddock area and a further team that is located back in the team headquarters. All of these people must operate as a single unit to ensure the car remains competitive and that correct choices are made at all stages of an event.
The similarities between these situations becomes more obvious when communications are considered. Within both Formula 1 and software development, teams must be able to communicate quickly and efficiently to ensure focus is maintained on the correct tasks. Communication channels between multiple teams need to be clear with common terminology used. Decisions and findings must be reported to decision makers quickly and clearly to ensure the timeliness and relevance of information.
Many software companies are still experimenting with how to best achieve this in their environment. A variety of Agile scaling frameworks are used and customised, some companies have found a solution that works for them, many of them haven’t.
# Procedures
Another items software development could learn from Formula 1 is the importance of clearly defined procedures for regular and disaster recovery tasks.
Formula 1 teams have clear procedures for a large number of events, from a normal pitstop to resetting the car’s electronics while on track, from proscribed engine changes over an event to emergency car rebuilds due to an accident. In Formula 1 it is not uncommon to hear a driver experience a problem during a race and within seconds instructions are relayed over the radio to change settings on the car to rectify or avoid the problem. It simply isn’t possible for the driver or the driver’s race engineer to know all of these settings; instead messages are communicated back to base where someone is able to rapidly search a procedure manual, locate the correct set of changes and relay them back to the driver. At this weekend’s Abu Dhabi event, in the first practice session, Daniel Ricciardo’s engine failed; according to the commentators an engine change normally takes around 6 hours, but with only three hours between sessions the team used a different procedure (likely with less checks and testing) to complete the engine change and get the car back on track for the following session; both of these engine change procedures would have been documented to reduce or eliminate the chance of unexpected consequences.
In software development we often deprioritise documentation in favour of introducing new features. If documentation is written, procedures are generated for the most likely scenarios, procedures are added for other scenarios as they are encountered, and the procedure manual is easily searchable, then the ability for a developer to resolve an issue becomes easier and potential failure points are easier to identify. Solutions can also be developed to improve the response to known issues.
# Preventing Further Issues
So far, I’ve concentrated on what can be learnt from Formula 1 teams and drivers, but what about learnings from Formula 1 as a sport?
In Formula 1 when something goes wrong it can have tragic consequences; this has resulted in the sport identifying ways to improve from both the ultimate tragedy of a death caused by the sport, but also from close calls where there was the potential for tragedy. An example of each of these is the introduction of the Virtual Safety Car (VSC) after the death of Jules Bianchi at the Japanese Grand Prix in 2014, and the introduction of the halo in part from the impact that took Jules Bianchi’s life but also due to incidents like the one that fractured Felipe Massa’s skull at the Hungarian Grand Prix in 2009.
Software development teams can learn from Formula 1’s implementation of the Safety Car and the Virtual Safety car in terms of incident management. When an incident occurs in Formula 1 it is highly likely that a further incident will occur due to the initial incident. For this reason, when an incident occurs the entire racing field is neutralised. In software development we can have procedures in place to prevent an incident from snowballing across our systems to create a much larger problem; this could be a system that limits activity or reduces the throughput of some systems so as not to overload a degraded system, or it could be a willingness to shut down an entire system in order to resolve an issue in isolation.
# Constant Iterative Improvement
Formula 1 has constantly worked to improve the safety of events and cars. In the 1950s and 60s there were 15 deaths in each decade, this decade there have been only 4 (deaths occurring at official Formula 1 race weekends). After every fatality or serious incident both the FIA and Formula 1 teams work to improve safety, often introducing safety improvements mid-season. Additionally, as Formula 1 is constantly pushing technological knowledge boundaries, and especially in the 1970s, the rules were often adjusted to outlaw certain technologies for both safety and competitive reasons.
Although software development generally doesn’t cause deaths (this could be argued on many fronts, but as the percentage of all software that can directly cause a death is so low I’m rounding it to 0), we can learn from this iterative improvement Formula 1 has applied to their rules and safety features. Many times, I’ve seen software development organisations release a “completed” product in a big bang release, if these changes are not accepted by customers and users (the Formula 1 equivalent would be the changes are outlawed) then the entire investment in the changes are wasted. Instead we should be honouring the principles of the Agile Manifesto and deliver frequently and iteratively to enable the validation of ideas and prevent waste of development time and effort.