McDonald’s McDrive Over-engineering “Lessons Learnt” for Developers

Next time you're using a McDonald's "McDrive" drive-through restaurant, note carefully how many service windows they build - and then compare this to how many they use. A typical McDrive offers three or five service windows. However, you'd be hard-pressed to ever be served at any more than two.

I often use this analogy when discussing overly complex software architectures. I would think that when designing a drive-thru, getting customers in and out is a key objective of the design. It therefore makes sense that by being able to run the order taking and delivery operations in parallel you should be able to get the cars through quicker. But why are most of these windows closed?

Some of the worst software architecture designs involve adding too much complexity for the sake of getting some perceived value out at the other end. However if you make the architecutre too inaccessible, it becomes impossible to realise those benefits. This problem is compounded by the fact that for the most part architectures are designed by talented and experienced developers but are consumed by developers who just don't get what the developers are trying to get at. It pays to make the actual consumption of the architecture as simple as possible, because that's the only way to make delivery and maintenance of software based on that architecture work from a commercial perspective.

Coming back to McDrive, the same is true. It's just not possible for someone who didn't design the drive-thru and is basically not interested in the principles for the design to understand how to consume it. The reason why multiple order taking and receipt windows don't work is because someone with a car full of kids struggling to cope with their day is not going to be able to remember which window to collect their order from. As soon as they get to the wrong window, the whole architecture falls apart and the principle rule - i.e. get people through the drive-thru as quickly as possible fails.

If you design a software architecture that is too complicated, that is too distant from the normal way of writing code by being too "magical", the same thing will happen. The less good developers on the team simply will not know how to use it properly and will either a) use it wrong and create occult problems that are impossible to track down and come up at exactly the wrong moment or b) not be able to progress through their work quickly. Either way, your architectural principles will probably fail - providing those principles are based on a sound focus on the commercials of the business and aren't technology led. (Watch for a future article on that very issue.)

- Matthew Baxter-Reynolds

Back to "IT Direction"