We are all very well aware that software has taken up an increasingly important role in all of our daily lives, but every now and then I encounter a new area where software is playing an ever-greater role. The latest interest being Formula 1 (F1) racing.

Formula 1 is, by its nature, a sport that tries to be at the cutting edge of what is technologically possible, however it’s also one of the most regulated with a myriad of rules to try to keep things “fair” and safe. One of these rules revolves around testing, with Formula 1 teams only able to test their cars on the track 12 days a year with no more than 4 days in any one stretch (rules can be found here). Essentially, this forces teams into a more waterfall model of development (for the software and equipment) versus an agile development style.

This unsurprisingly results in unpleasant discoveries, which the Renault Formula 1 team recently experienced where in a full day they were only able to complete 37 laps due to software glitches. Essentially they lost nearly 25% (1/4 days) of their testing time prior to the beginning of the season.

A counter example to this would the experience that the Haas Formula 1 team’s had.

Haas teamed up with Ferrari, prior to entering Formula 1, allowing them to do an unlimited amount of testing due to them not technically being a team at the time. The result of this was that Haas was able to reach the middle of the pack in terms of performance in contrast to other ‘new’ F1 teams who had already been in F1 for years.

This result speaks to the importance and impact testing can have and the difference between testing constantly like you would do in an agile methodology versus only testing at the end like in a waterfall model.

Agile isn’t necessarily right for every industry or every situation, but when you’re constantly making minute changes to achieve fractions of a second in performance it could be the best solution. I would love to see that evolution in F1.