Once a small and largely Los Angeles-based company, Pex is now a growing, remote organization. Because of this, what once had been an effective way for us to communicate and collaborate may no longer serve the needs of our team. Consider these examples.
When Pex started, everyone got a birthday cake and a party on their birthday. As it grew, people got a cake. As it grew further, there was a cake a month to pool birthdays together. Today, everyone gets the day off. (Arguably a better perk than a cake, but that’s beside the point.) The greater the size, the fewer cakes. The number of cakes per person was inverse to the number of people.
On the other hand, as the number of people increases, communication channels between them increase exponentially, as in communication channels = n (n-1)/2. The number of available communication channels skyrockets. By the time we have only 14 people, we have 91 possible channels. By the time we have 100, we have 4,950.
Definition of Done
Ever-greater communication and complexity comes with the ever-increasing number of humans who need to understand each other. Thankfully, when it comes to work processes, shorthand and systems help us navigate scale. One of those shorthands is a “Definition of Done.”
Traditionally, a Definition of Done (or DoD) means “deployed to production.” That’s important and great, but unless we are specific about precisely what we mean and what it takes to get there, we introduce unnecessary risk (a.k.a. opportunities for confusion, delay, hidden dependencies, or mistakes.)
Because of Pex’s recent growth, we needed to create the kind of clarity and precision that makes it easier to complete great work across multiple, asynchronous teams. Our DoD creates a shorthand and a built-in checklist that ensures everything is covered. Checklists are powerful. Thanks to the popularity of The Checklist Manifesto, we know they have saved lives by reducing airline crashes and improving surgical outcomes. We use one to create excellence and safety too, even if we aren’t saving lives. And to make it built-in, we automate as much of the DoD checklist as we can.
So what do we mean by done?
Boiled down, “done” means five things:
- It’s code complete
- It’s integrated
- It’s tested
- It’s documented
- It meets relevant NFRs (Non-Functional Requirements)
The code is written! We’ve met all the acceptance criteria, peer reviews are complete, and blocking comments are resolved.
Code is checked in, and the automated build is stable.
Fast feedback loops are key here, starting with the smallest units and time intervals and building from there. Unit tests, integration tests, regression tests run ideally within minutes or at least the same day. We augment this with strategic manual testing.
Documentation debt can become the silent killer, especially during rapid growth. To combat this, we write it in the smallest batches possible. Cleanly commented code, clear PR descriptions (using a template that makes it easy for everyone to create good PR documentation), and automated API docs are some building blocks.
These are how the system is rather than what it does. These are often known as the -ities (e.g., scalability, maintainability, reliability.) As part of design and delivery, the definition of NFRs is a collaboration between Product, Engineering, SRE, and Business to ensure the system behaves the way it needs to. For example, we make good choices so that code is maintainable (e.g., use only trusted base images); we agree on performance targets that are feasible, valuable, and ensure usability; we add logging and alerts to provide observability.
Bringing it all together
Agreeing on what we all mean by “done” ensures we’ve accounted for all the kinds of work, automated or otherwise, that it takes to ship something with excellence. We avoid confusion between “done,” “done-done,” and “really done.” And we have a shorthand, a.k.a. the DoD.
Interested in helping us get things done at Pex?
We’re hiring! View our open roles.