How Pastries Collapse and Custom Software Projects Fail

Unspoken assumptions and hidden constraints — these are the causes of both pastry collapse and project failure. Let my culinary mistakes guide you past the big mistakes that can plague custom software projects, be it a major modernization or a simple update. Whoever you work with to build your dream app should help you navigate this stuff.

🤩 In the beginning, there’s starry-eyed optimism.

This Thanksgiving, after years of watching the Great British Baking Show, I found myself itching to try my hand at making full puff pastry. Tired of the traditional turkey tomfoolery, I wanted to reframe the classic holiday ingredients into a saucy, crispy, airy vol-au-vent shell that everyone would love. Not content with the perfectly serviceable store-bought puff pastry, I wanted to make it myself. And not just the quick and easy rough puff, no. I wanted to make full. puff. pastry.

I was imagining something like this:

Instead, I got this:

A lot of custom software projects start the same way.

Having used modern web apps for years, you find yourself itching to replace that old, creaky desktop app that you use to manage your business. The idea is to reframe the business tool as a fresh, light, responsive web app that everyone will love to use on their iPads and smartwatches. You gather your team, be it in-house developers, or an agency like ours, and you give them a brief.

You imagine something like this:

But too often, you wind up with something like this:

🧈 Here’s what unspoken assumptions and high-fat butter have in common.

While high on bake-off enthusiasm, I googled a bit, found a reputable-looking recipe, and wrote out my plan.

Full puff pastry is simple. Just flour, salt, water, and butter. Make a dough rectangle using everything but the butter. Make the butter into a matching rectangle, then fold them together to make a stack of alternating layers of dough and butter. Rest that in the fridge and repeat a bunch of times. What could go wrong?

A lot, it turns out. What my recipe didn’t convey were some unspoken assumptions and missing steps. This included things that the author had mixed so deeply into their subconscious that they no longer registered as assumptions, any more than “walk over to the fridge before trying to open it” would seem like an assumption to you or me.

For my pastry, there were two unspoken assumptions:

1. Use high-fat butter
2. Thaw it a bit before trying to work with it

As a newbie, I didn’t know that the butter needed to be somewhat pliable before I started to fold. It’s obvious in retrospect, but at the time, I was operating under the apprehension that too-soft butter was the bane of full puff. I also had no idea that butter could be differently fatted. More fat = more pliability. Consequently, I spent a lot of energy pounding a nearly frozen butter brick with a rolling pin trying to turn it into a thin rectangle.

I wound up with a sore shoulder and a horribly cracked rectangle of low(er) fat butter. When I tried to fold it into the dough, it broke into hundreds of little butter cobblestones. These would eventually ruin my lamination and produce the crackers you saw above.

Of course, by the time I made that first fold, it was already too late to fix the problem. My pastry was dead on the counter, and I hadn’t even pre-heated the oven yet.

📈 Hidden assumptions lurk in complex business models.

All custom software projects start with an overly-simplistic plan like, “Just make the website look like the old app.” You’ll need a database, a little compute power, somewhere to put the files. Simple. What could go wrong?

A lot. What that description doesn’t convey are the thousands of unspoken assumptions and hidden constraints. You’ve forgotten them because your current system takes care of these for you. If you’re modernizing an existing system, you can count on finding some of these while building your new app or updating your old one. We call them Last Thursdays.

A good consultant will ask you seemingly inane questions to try to draw these out. They aren’t being difficult when they ask you, “When you have to re-issue an invoice, do you overwrite the old one, or make a new, corrected invoice with the same invoice number?” Instead, they’re trying to tease out the “let the butter thaw a bit” kind of steps that are easy to miss and difficult to account for later on. It’s easy to let the butter thaw when you just pulled it out of the fridge, but once your pastry’s in the oven, it’s too late.

🤷 Nobody intends to hide constraints.

Over the years, I’ve run into a lot of unspoken assumptions and said a lot of things while not speaking some of my own assumptions. These are a few of my favorites:

• The ask: Copy our old database into a modern, managed database system. The hidden constraint: there are actually 20 independent old databases. Some data overlap, and some of that overlapping data doesn’t match up.
• The ask: Connect to this low-energy Bluetooth device and read accelerometer data from it. The unspoken assumption: the BLE device will be surrounded by 40 other identical devices and sometimes we want to connect to more than one at a time.
• The ask: Build a database table to hold pricing records for each of our products. The unspoken assumption: each pricing record is actually 10 different records, each with its own unique business value, ownership model, and source of truth. They all need to be independently versioned in a way that our accounting team can audit.
• The ask: Build a mobile app that works only on phones. None of our customers use iPads. The hidden constraint: The project sponsor uses an iPad and wants it to work on that too.

In every case, we uncovered the assumptions and constraints early. We did that by building rapport and establishing open lines of communication. My team and I could ask obnoxious questions like, “Who’s in charge of changing the pricing record?” and, “Does anybody in your company use an iPad?”

These assumptions never go unspoken on purpose or out of malice. Usually, it’s just difficult to know ahead of time what matters and what doesn’t. Humans are really good at optimizing what they focus on. If it’s a problem that’s already been solved, your brain literally might be unable to remind you that it once was a problem until you’re presented with the right question.

That’s why a good consultant will ask a ton of questions, sometimes more than once. It’s not (usually) because they forgot or are being willfully obtuse. They’re usually to try to shake loose any constraint or assumption that our collective brains are hiding from us.

We also do our best to remove any value-laden language from our questions when teasing out constraints. Instead of, “Why didn’t you tell me that sooner?” a good consultant aims for, “Look at what we just discovered together!”

🥐 Sometimes, it’s best to use frozen pastry and off-the-shelf software.

When I pulled my pastry cracker out of the oven, two days before Thanksgiving, I had a decision to make. Should I try my custom pastry again or go with the sure thing and buy some frozen pastry dough? There was a lot of other cooking that needed to happen in those two days, and I had exhausted my time budget for trying new things. For the sake of my family’s happiness, I switched to store-bought, and it worked out perfectly. The nicer-looking photo above ☝️ is my first attempt when using frozen puff.

I’ll definitely try my hand at artisanal pastry again someday. But this time, I opted to leverage the centuries of human effort and time that has gone into producing a commercialized version of puff pastry for home chefs. The people that made that product have made all the mistakes that I’ve made, and many, many more on the way to uncovering all the unspoken assumptions and hidden constraints of pastry making.

An artisanal approach is fun, but you have to know going into it that you’re going to stumble a lot while discovering all the things that the professionals have forgotten to tell you.

Software is no different. Atomic is a custom software consultancy. I relish the challenge of uncovering hidden constraints. And my advice to new customers is to build as little custom software as possible. When you use a commercialized product like Excel, you’re leveraging centuries of human thought and effort about how to effectively process spreadsheets. If my team builds one for you, we’ll do our level best, but we will miss something.

Know that the “custom” part of custom software projects is risky.

That isn’t to say that you shouldn’t build any custom software. But you have to enter into it knowing that the custom part will be risky. We’ll uncover assumptions about your business and your existing software or human process that neither we, nor you realized at the outset. For that reason, we do our best to leverage as much pre-existing work as possible.

For my Thanksgiving vol-au-vent, I still made a custom filling, tailored to my exact preferences. But instead of customizing every aspect of the dish, I wrapped the filling in a commercial pastry shell that was fool-proof. The result was a delicious blend of custom and off-the-shelf. My guests were happy, and I got to play with flavors without throwing out my shoulder flattening another low-fat butter brick.