Exercise in Thinking: Do Racing Stripes Make a Car Go Faster?

The progress from a junior to a senior software developer shows in various ways:

• Coding: Years of working with different languages, frameworks, libraries and architectures help developing a gut feeling for technology.
• Planning: Having experienced a large number of projects or product releases with their milestones, last-minute changes, hotfixes, updates, etc., senior developers usually have a better sense of what to do and what to avoid.
• Analytical thinking: (Good) senior developers tend to ask the right question at the right time, digging deep to find out what they don’t know – and whether what they think they know is true.

For developers, improving their analytical skills is an important part of personal growth. That is why I like to cover non-technical topics both in my conference talks as well in my blog articles.

In a previous post called “How to Approach Problems in Development (and Pretty Much Everywhere Else)”, I wrote about (among other things) what Indiana Jones can teach you about problem solving.

The article you are reading now asks whether “racing stripes” make a car go faster. A strange question on a software development blog. This is by design, because strange things tend to be remembered more easily (fun fact: The word “strange” can be translated to German as “merkwürdig”, which in a literal translation back to English could be “worthy to be noticed” or “worthy to be remembered”).

So: Do Racing Stripes Make a Car Go Faster?

When being pressed for a quick answer, most of us would likely go for a “No”.

On second thought, various considerations come into mind:

• Is the racing stripe applied in addition to the existing paint job?
• What about the weight of the paint for the racing stripe?
• What if the stripe is not done in paint, but with adhesive film?
• Or what if the whole paint job is replaced with a design including a racing stripe – and lighter paint is used?
• How much does the weight of the paint influence the car’s performance, anyway?
• …

Many well-intentioned questions, unfortunately focusing too much on details. On the other hand, one important question is missing: What kind of “car” are we talking about here, exactly?

What if the question is actually about toy cars?

• The car in question is now significantly smaller, while the size of the air molecules stays the same. Does aerodynamics play an important role here?
• Does the car have an engine? If not, is the car intended to roll down a hill? Maybe then more weight could be beneficial?

But: Are we not missing something here? If “car” was not what we expected, are our assumptions about “faster” still valid?

• What do we know about the context of the question?
• How exactly is “faster” determined?

Now imagine the following situation: You give two identical toy cars to a young child with an interest in cars. One car has a racing stripe (or a cool design in general), the other does not.

Now you ask the child “which car is faster?”, and if the child answers “the one with the stripes”, then this is the correct answer (for this child).

From our grown-up point of view, the faster car is the one that travels more units of distance per unit time. From the child’s point of view, the car that wins the race in their mind (“wroom, wroom!”) is the faster one. The laws of physics do not necessarily apply here.

Lessons learned

Be careful with your assumptions

Your personal experiences are an important foundation, but they can also mislead you. Be careful when assuming facts that were not explicitly mentioned. You may be subject to a misunderstanding. And even if not, “obvious” questions can still yield helpful information. If you have the chance to ask, use the opportunity. You never know when a question like “just to be sure, we are talking about X that does Y?” is answered “yes, exactly… well, ok, Z should be mentioned, too” – with Z being a vital detail.

Make sure terms are clearly defined

When you talk about X, make sure that you and everybody else agrees on what X is exactly. Take the term “combo box”, for example. Even though the word “combo” clearly hints at a combination (of a dropdown list and a text field), some people use the term “combo box” also for simple dropdown boxes.

From a technical point of view, this may be only “half wrong”, because in certain UI technologies, a combo box control can be turned into a dropdown list as an option.

But when speaking to colleagues or customers, this may lead to unnecessary confusion or even wrong expectations.

Be sure to know the context

A car on the street is different from a toy car in the hands of a young child.

A software that is a pleasure to use on your laptop while sitting on the couch can be a pain to use on a smartphone while trying to catch a train.

And for transferring huge amounts of data from location A to location B, a truck full of hard drives can be both a viable solution as well as a terrible idea.

Context matters. A lot.

Fully respect the target audience and their view of the world

This is where empathy comes into play, “the capacity to understand what another person is experiencing from within the other person's frame of reference, i.e., the capacity to place oneself in another's shoes” (quote).

For technical-minded people, empathy may sound like a touchy-feely topic, “about being nice to people”. For me, empathy in software development is about respect towards users and about being a professional.

If you are interested, I have published two articles about empathy with a focus on software development here on this blog (“The Importance of Empathy” and “It’s Good for You, Too!”).