Understanding what really matters in your problem space

Two very similar math problems…


Problem 1:
If a car goes 20 mph down an open road for 1 minute and then 40 mph down the road for another minute, what was the car’s average speed during the entire ride?

Most people will answer the question correctly – 30 mph.


Problem 2:
If a car goes 20 mph down an open road for 1 mile and then 40 mph down the road for another mile, what was the car’s average speed during the entire ride?

Many people would guess that the answer is 30 mph again.*

The two scenarios seem like they’re asking the same thing. If you think to hastily, you might convince yourself that they really are. But, they are really two fundamentally different kinds of comparisons. The first averages two speeds traveled over the same amount of time. The second averages two speeds over different amounts of time – masked by the fact that the distances are the same.

If you simply rephrase problem 2 as, “If a car goes 20 mph down an open road for 3 minutes, and then 40 mph down the road for 90 seconds, what was the average speed?” (i.e. the same question posed using time instead of distance) most people would quickly see the answer is not 30 mph.

What’s my point?

Knowing when a pattern is a pattern
Building software presents the same kind of mental brain teasers as these little math problems. When there’s estimates and timelines in play, understanding when a problem space is the same as another problem space, and when it is not, is critical. It’s easy to think about reusability in the abstract sense, but often times code and ideas that appear quite reusable, sometimes are hardly reusable at all.

What really matters?
Just because the math problems seem to live in the same problem space (a car, driving at two different speeds for a common interval, and some math), the real crux of the problem lies in the difference: a common interval of time v. a common interval of distance.

All the similar parts really don’t affect the problem space that much. In other words, swapping the car out for a moped, the road for a back alley, or going 40mph first and then 20mph second, have no impact on the problem you’re trying to solve.

When we design software, we need to think about the problem space the same way. Is what I’m building now similar to what I built a year ago because they are both social networking apps? Because I’m working with the same developers? Because we’re using the same technology? Because we’ll use the same architecture?

What differences and similarities really matter? Perhaps it’s the most important question to answer when you want to understand the problem your trying to solve.

* The correct answer is (roughly) 26.67 mph.