The Cookie Story: When Build Failures Became Sweet Accountability

Based on a true story.
Our project began on a brisk Monday morning, with twelve of us gathered around a whiteboard in a room filled with fresh coffee and nervous energy. Most of the team had never tried trunk‑based development before; the phrase itself was nearly foreign. Yet from day one, our engineering manager insisted we all commit directly to the trunk (yes, it was the era of svn). No long‑lived forks. No feature branches lingering for days or weeks. It felt risky, but he believed that small, frequent commits would build momentum—and trust.
To keep us honest, we set up a simple script in our repository called cookies.sh:
mvn clean test && mvn verify -Dgroups=cookies
This script had to be run locally before the code is pushed. Every time someone pushes code, the full test suite runs. If it failed, that engineer owed the team cookies—real cookies. At first, this ritual felt like a polite trap: suddenly we were surrounded by brownies, chocolate chip delights, and oatmeal raisin disasters. We joked that our project was powered by sugar.
Pair programming sessions became the heart of our workflow. 100% of the time. Two engineers sat side by side—switching roles every twenty-forty minutes—reviewing each other’s code in real time. Mistakes that might have slipped onto the trunk were caught immediately, and the feedback loop was almost instantaneous. Our commits stayed small: a bug fix here, an API tweak there. Every successful build brought a small burst of satisfaction, and every failed build led to a shared treat and a lesson learned.
As weeks turned into months, something unexpected happened: we stabilized. The frequency of test failures dropped. Our bodies eventually recovered from the initial cookie onslaught, and as a team, we agreed to start bringing fruit or healthier options instead of the usual carb-heavy treats. Almond-flour muffins and yogurt with berries gradually replaced brownies and pastries, turning our build failures into something a bit less damaging to our diets.
Behind this steady progress was our engineering manager’s steady hand. He never forced us into jargon or hollow promises of “industrial‑strength agility.” Instead, he calmly walked through test failures with us, encouraged open discussion when builds broke, and celebrated every on‑time feature delivery. His leadership wasn’t about buzzwords; it was about creating an environment where we could learn, share responsibility, and improve every day.
He was also a strong advocate for Extreme Programming (XP), and to our surprise—it actually worked. Practices like pair programming, continuous integration, and relentless testing didn’t just stay on the whiteboard; they became part of our routine. We also embraced one of his favorite lessons: real progress often comes with pain and discomfort. If tests were too slow, we rewrote them—even if it took days. If they were flaky, we ran them dozens of times, tracked down the root cause, and fixed it properly. If our internal APIs were awkward to use, we refactored them until they made sense.
It was through facing these small pains head-on that we built something better. No shortcuts, no magic frameworks—just the discipline to improve things when they were hard, and the leadership to make that mindset part of our culture.
Another discipline that shaped our daily work was the SOLID principles. They became our mantra. Every change we made was viewed through that lens, which helped us spot bad design early and push back when necessary. Over time, it became easier to keep things simple, intentional, and clean. Combined with strict TDD, this mindset led to better design decisions and gave us confidence that our code was both correct and maintainable. It wasn’t perfect, but it worked well—most of the time.
Over time, we’d discovered that committing to the trunk wasn’t just a branching strategy—it was a way to keep our focus narrow, our feedback loops tight, and our team bonded. We finished with a lean codebase, a healthier snack rotation, and a newfound confidence that we could tackle any complex challenge—one small commit at a time.