There’s a little story I always think about when designing or modifying an established, well entrenched API, and it goes like this:
Back a few decades ago, no cars had cupholders. A team of engineers were given the task to add a few cupholders to the new car model, so they went down to their local convenience store (like 7-11) and bought all the varieties of cups that the store had. They then analyzed the cups and designed a cupholder for the car that would work with all the different sizes of cups, and put it in their new car.
Fast forward a few decades, and all the cars had cupholders. The convenience store had to design a few new cups to accommodate new demands, so they went to their office parking lot and measured all the car’s cupholders. The analyzed the car cupholder data, and came up with a cup that fit most the cars in the parking lot.
Now, I have no idea whether this story is true or not. I would guess that it’s not true if I were a betting man, but its somewhat reasonable that it could have happened. I’ve seen things like this happen first hand, where you have two moving targets designing for each other. But it does illustrate a problem that often happens when two distinct teams are designing around each other.
The core of the problem is that the two teams are designing around each other, and not coming to an agreement on what to get done. Toyota shoots to meet the changing requirements of 7/11 and 7/11 shoots meet the changing requirements of Toyota, and the result is that both teams miss the mark slightly.
In this situation, 7/11 and Toyota probably don’t have a very strong relationship, so thats expected. Even within one company though, this happens between teams if you don’t come to clearly defined specifications. Team A designs an api to finish processing some task in 10 ms for Team B. While Team A is working on that api, Team B accepts a new task to add more functionality, and they now need the task to be done in 5ms! The options are that 1) Team A has to unfairly work extra hard to cover the changing requirements or else 2) Team B will look foolish. Neither of these are good, 2) has immediate consequences and 1) will lead to Team A burnout eventually.
I don’t have any grand sweeping conclusions about this I can sum up in one sentence. Most people have probably stopped reading by this paragraph even. 🙂 I’m sure that if you’ve worked in engineering teams before, you’ll have had experience in situations like this, and your experience will be a stronger anecdote than anything I can say about my little story. Just think when you’re working, am I designing for the specification, or am I specifying the design?