Embrace imperfection, avoid flail, and develop software with confidence
One of the challenges of software development is that it’s so tempting to just ... change stuff. It’s sooo easy to add a little here and tweak a little there just because you feel like it. Or, in some companies, you might show up to work only to find an influential executive has had a visionary shower-thought they're convinced will be a "game changer."
Software is so malleable that while it’s reasonable to say anything is possible, it doesn’t follow that everything is possible.
When you're designing and developing while chasing a constantly moving target, it's hard to maintain a sufficient level of focus and directed momentum to truly finish arcs of work. Eventually, everyone's frustrated and wondering if you've completely lost direction.
That’s the double-edged sword. Software is so malleable that while it’s reasonable to say anything is possible, it doesn’t follow that everything is possible.
You have to pick your battles and see them through.
Loop Forever: Dogma→Product→Insights
Recognizing that, like everyone else, we at Fullstory are likely to fall into these predictable, dumb patterns, we saw a need for a conceptual framework that could mitigate those frustrating aspects of product development. What we wanted was a way of expressing our shared goal of evolving quickly but avoid flailing–a structured approach that would keep us mind-melded and help us move cohesively as a team. And we needed a way of communicating expectations about each iteration of the creative process so no one would be surprised where we ended up.
The concrete result of our abstract needs? A silly but evocative diagram. An approach to structuring our wrongness so as to reliably reduce it over time.
We call it The Suck Less Cycle.
The Suck Less Cycle is an iterative loop. You can have short iterations or long ones, but the point is, this is a cycle you repeat forever. And if you’re doing it right, with each turn you get a little bit better, and suck a little bit less.
So how does it work?
Step 1: Dogma
The first and most important step is establishing the Dogma about how you think you should proceed. "Dogma" was chosen intentionally because your assertions aren’t facts. They are hypotheses—sometimes just guesses—about how to operate so as to produce some desired future outcomes.
Critically, during any one iteration of the Cycle, everyone agrees to show deep and abiding reverence for the current Dogma as if it were revealed truth handed down by Lord Huron himself. Yes, deep down you’ll know that sometimes your Dogma includes wild-ass guesses as to the best way forward, but at least they’ll be well-articulated wild-ass guesses.
Here’s an example set of tenets your team might decide to adopt as Dogma:
We should build features A, B, C instead of features X, Y, Z.
We should prioritize fixing bugs over adding new features.
Our homepage should load in less than 100 milliseconds on a 10Mb cell network.
...any other tenet you choose that helps everyone proceed unambiguously...
Each tenet helps you make decisions about what to work on when while setting clear expectations for everyone else on your team.
Should we start developing marketing materials for feature Y? No. For feature B? Yes!
Should we expect more bugs to be fixed and feature development to be slower?Yes.
Our homepage takes 3 seconds to load on a smartphone. Is that bad? Yes.
...and so on...
It's typically easy to get buy-in from all the stakeholders for this sort of Dogma, at least for one iteration of the Suck Less Cycle, because it's just so...clear.
Because Dogma is the solid foundation upon which the Suck Less Cycle is built, we'll return to it in even more depth below.
Step 2: Product
With clearly established Dogma–we like to say "we've banged the gavel"–you now have conceptual cover to justify embarking on a substantial arc of work towards building Product. You can act without the ground shifting beneath your feet. Since you’ve front-loaded the understanding of how you’ll proceed, you can move faster and more autonomously. You don’t have to “check in” all the time to see if anything has changed. It won’t have changed because it can’t change! Why? Because Dogma!
(At least until the next iteration of the Cycle.)
Thus, you can make progress fearlessly, and eventually, launch your Product. And now that you’ve got yourself a Product (or an update to an existing product) it's time for Insight.
Step 3: Insight
Your new work is out there, so now you have the opportunity to support it and observe how it’s used. In other words, you’re gaining real-world evidence, which is the best way to pressure-test your Dogma. Analysis follows, and with a little luck you’ll gain some insight that you can use to update your Dogma for next time ‘round, either by reinforcing tenets that worked out well or changing prior assumptions based on evidence.
The Suck Less Cycle helps you relax about being wrong
None of this is rocket science, so why even have this diagram? And why is it all about “sucking less?" Calling this loop “The Suck Less Cycle” helps everybody chill out about the fact that, yeah, we suck in a lot of ways. Acknowledge the imperfection. It's okay!
Building great software is not about being perfect. It’s about reliably making progress.
Of course, we all want everything to be perfect. And things could always be better, if only because the goalposts shift to an ever-more-exciting vision as a product evolves. We’re always falling short of our imagination. Embrace it! Accepting that you don't have to be once-and-for-all right, all the time, is liberating.
It’s hard to be creative and effective when you’re anxious or fearful about failure. Being innovative usually requires taking risks, and they don't always work out. Putting the sentiment right there in the title–WE SUCK!–removes the sting. It’s a self-seriousness pressure relief valve.
Building great software is not about being perfect. It’s about reliably making progress.
Dogma! You can’t change all the things all the time
If you're getting into the Suck Less Cycle, it's worth digging deeper on why the notion of Dogma is so critical.
The explicit presence of Dogma in the diagram is everyone's reminder that you can’t just change all the things all the time. Some guardrails simply must be set in stone for a while.
Such constraints turbo-charge creativity by focusing invention toward clear goals, and your Dogma creates space for designers and developers to feel that they are able to truly solve a problem well. Anything less than well is bound to inhibit your potential insight, because nobody trusts the outcome. Anything less than well, and you'd be inclined to say, “We’re only getting bad results because we didn’t get a chance to really do what we planned before getting randomized.”
Dogma breaks the above chicken-and-egg paradox, so that you can trust the outcome, gain reliable insight, and learn institutional lessons about what works and what doesn't.
Dogma? You can change next time ‘round, though
But! Because it’s a cycle, it’s explicit that, yeah, we can change our thinking—so long as it's the right time. Not midstream.
E.g. “We’re doing X, you think we should do Y. That’s fine. I hear you. Next time we want to update our worldview, we’ll consider Y. And when we do, we’ll have evidence of how X worked or didn’t work. We can use what we learn from X when we consider new things.”
(Importantly, Dogma is both an input and an output, and it should change over time. How does Dogma change? At Fullstory, we have a special kind of meeting we call a "Prove It" which we’ll talk more about in a future post.)
Having a Dogma in the fight
If you can't know whether you were right or wrong, you can't improve.
The very act of stating your Dogma–and making a habit of talking about Dogma as a first-class thing–is powerful because it forces you to communicate important concepts broadly that might otherwise go unstated.
Write your Dogma down. Only by having recorded what you thought would be true in the future can you know, later, whether you were right or wrong. If you can't know whether you were right or wrong, you can't improve. By contrast, if you never really take a position, you can’t really know how you should evolve it.
May we all strive to suck less
As simplistic as this framework may be, The Suck Less Cycle has a clear effect on how our whole company operates at Fullstory. Leveraging Dogma to effectively communicate and execute while accepting and embracing the reality of never-ending improvement, we get excited about the marathon, knowing that with each turn we know a little bit more and suck a little bit less.
If this article triggers any thoughts, if you've seen alternative approaches to solving the same problems, or if I can clarify anything about the Suck Less Cycle, let's discuss in the comments below.
Perhaps with a dose of Dogma and a simple intent to "suck less" we can return a little health and sanity to software development.
