The Chaos in the Matryoshka

Those that know me know that I’m not afraid of change. I’m a big proponent of “strong opinions loosely held”. When something makes sense, grab ahold, if you can disprove it, move along. Don’t become too attached or you’ll find you’ve turned into an apologist.

About 4 years ago I announced I was done with fixed price projects. It was the best business move I ever made.

There wasn’t really any change in the amount of money we made on each project. But the spirit of collaboration we were able to bring to customers, stopping the seemingly constant disagreements over what was included or not included, what was a bug or not a bug, just ceased for the customers that understood what we were about. Software development became fun again, fulfilling. We have delivered much better work because of it.

Of course, the odd customer (who we’ve gotten better at purging) would still want to argue these points. For whatever reason, maybe they grew up in a world of fixed-price contracts, they’d try and turn collaboration into confrontation. Try and change the terms of our engagement.

I spend a lot of time thinking about the whys and hows of this, and I think it comes down to this - they’ve become blind to the chaos around them.

Chaos is everywhere, and builds on itself. It starts with a poorly understood requirement, snowballs into misunderstood emails and conversations, avalanches into the maelstrom of shifts in understanding.

Chaos is deceiving. It wears a mask of order and alignment. The human brain is brilliant at finding patterns, and it is so tuned to the idea of patterns that it will perceive them where none exist. Countless times, a customer has presented a requirement as a simple thing, we listen, we write it down, “this should be trivial” we think. And then through conversation and examination the mask comes off. Then we find it’s like a matryoshka doll, behind each mask is yet another that appears ordered and aligned. Eventually deep enough into the project we take apart the last piece and voila, chaos.

Real life is messy. Countless times we’ve had the conversation around the whiteboard where we’ve just scrapped a really elegant data model saying “Wow, this is awful! If only this business case didn’t exist…” We just discovered the chaos in the middle of the matryoshka.

Customers tend to get this. They know their business is complicated. Sometimes they’ve been ingrained in it so long that they’ve become blind to the ways in which it is complicated, but when things are drawn out logically they tend to say things like “Yeah, I know it’s strange, but that’s just the way it is.”

The risk in the software project lies in not knowing how deep in the matryoshka the chaos lies.

A fixed-price fixed-feature contract expects the software developer, with little to no prior knowledge of the customer’s day to day business dealings, to take on that risk and price the project accordingly. They’ll take wild stabs, based on their own prior experiences, sometimes masking it in a thin veil of reason. A fixed-price contract will never reflect the true cost of the software, you’ve either bludgeoned the business into paying more than they should, or the developer into delivering more than they could afford to (or worse, they walk away).

A target-budget contract has more of a shared risk. The customer accepts that they may not have a “complete” solution at the end, but that it was fairly priced because it cost exactly according to the work that was put into it. The risk on the part of the software developer is simply that they do their job professionally, and engage the customer appropriately to explore taking the matryoshka apart.

Over the past couple years though we’ve very much enjoyed a more holistic and sustainable approach than target-budget, but that’s the subject of another post…