Car Racing and Software Development Have Something in Common

Enterprise-scale software development is bit like car racing. I’m not thinking about speed or agility. I’m thinking about complexity. Hear me out.

Let’s take NASCAR racing as an example. It looks simple. Drivers go round and round on a track as fast as they can. Fastest car wins, right? Not at all!

Racing crews win races not just individual drivers. A crew consists of the crew chief, tire changers, fueler, jack man, etc. In addition, there are racing teams. A team might have three or four drivers and crews in a race. Those drivers will help each other during the race using techniques like drafting and blocking.

Tires always have a major impact on race results. Crews make real-time decisions on when to change tires and whether to change all four or only two. Fresh tires are always better but changing four tires means spending more time in the pits.

Pit stops are a major factor in every race. No one ever runs a complete race without making pit stops. Crews employ varying strategies to maximize distance between pit stops and achieve the perfect balance between lap times and distance traveled. Many a race is won or lost in the pits.

The more people learn about NASCAR racing, the more they enjoy watching it.

What does this have to do with software development?

Like car racing, software development looks simple. Software team members write code, pool their efforts, iterate a few times, and deliver a final system. Simple, right?

Like car racing, there are other considerations — team dynamics, change requests, error handling, standards compliance, security controls, audit trails, report generation, data validation, response times, memory usage — to name a few.

Many aspects of enterprise software development are simply not apparent to observers outside our profession — just like the strategies used in car racing. Most of these aspects fall into the category of non-functional requirements. They are items and issues that are important to the proper operation of a software system and to the company’s ability to support the system. Yet, it’s hard to measure the business value they offer.

Educate and Engage

Those of us who build software systems need to do a better job educating business people about all the considerations around building high-quality enterprise software. At times, it seems that we want to know everything about how businesses operate, yet we closely guard our secrets for building software.

The more business people learn about the process of developing software, the more they will engage with us and become part of our development teams. Only then can we achieve real agility.

photo credit: Darryl W. Moran Photography via photo pin cc