Done doesn’t mean perfect for all time. It means, as Kevin McGillivray says, “we’ve done what we can with the time, energy, and resources available for today in response to the current (but shifting) reality in front of us.”

I’m done with this year. I’m also done building our waterfall, mentoring students at CareerFoundry and re-launching the Nigerian market alongside the Luno team. 

None of these were perfect, but accepting them has made it easier for me to transition between years, projects, and situations.

Of course, I’m not perfect, so I wasn’t able to accept all situations as done, causing some tension as I meandered through the year. Two of my previous posts, Deadlocks and Bigger Wholes and Designing a Product Like an Inuit Builds an Igloo, helped me reflect and understand this tension a bit more.

But, it wasn’t until Kevin McGilllivray’s post, “Is it Done” and his generous response to some of my questions, that I started to find rest in my work.

He was kind enough to allow me to re-share his response to my question on how to find rest in the tech industry, where it might sometimes feel like nothing is ever done.

•••

Being "at rest" is temporary. The painting (or software) is holding together, coherent, useful and/or enjoyable… for now. In this moment, although there are rough spots, the whole is holding together and the centers are supporting each other.

In other words, “done” doesn’t mean perfect for all time, it means we’ve done what we can with the time, energy, and resources available for today in response to the current (but shifting) reality in front of us.

Any further action would begin a new cycle of divergence and instability, followed by more work to re-stabilize. If we don’t have time or energy for that new cycle today, it’s time to be done, at least until we pick it up again.

Next week, tomorrow, or a few minutes from now, I’ll likely find something else that I want to add or adjust and the cycle starts again. Rest ends, action emerges, forces are imbalanced, until the adjustment is done and the whole is re-integrated.

As we look out at the larger whole and in at the smaller centers, we can always find more that could be done, but we don’t have an infinite supply of time or energy to do it. This is why perfectionism is an anti-pattern.

When we’re in the middle of things, we want to be tuned toward noticing areas of improvement, we want to look for mistakes and flaws and do what we can to address them. But we can’t do it all, and this is a good thing.

Perfectionism leads to focusing on too small details, within but separate from the whole, that end up dis-integrating the whole into fragments.

We accept the imperfection, informality, and roughness in order to maintain wholeness at each step. Roughness allows each center to hold together. And when we start to run low on resources we can make a tradeoff and find a stopping point.

What does this mean for software? Well, first, if we’re looking for the entire whole to feel “at rest” for all time… that’s never going to happen.

A painter has the benefit of eventually signing the canvas and moving on to something new. That doesn’t mean the painting is “done” though. It means it was time to move on and continue the larger whole (the overall practice of painting). Some paintings end up as sketches, some get developed to a deeper level of detail.

The goal of a business selling software is to provide a useful, enjoyable product that is valuable to customers, and at a larger level helps them do whatever they do to make the world more whole.

That requires ongoing adjustments and maintenance to stay in sync with the larger whole—customers, business needs, changing software interfaces. Otherwise entropy sets in quickly and the software becomes irrelevant, not useful, or not enjoyable.

So instead, we can consider a product to be “at rest” or stable and coherent enough to be able to release. That might be yearly or quarterly (operating system level releases), monthly to weekly (largish features), or daily to hourly (for “agile” cycles / bug fixes, etc.).

And that state of being at rest is likely to end very quickly. It’s a continual tending to areas that are becoming unbalanced. Tech debt and software rot is an ecosystem issue, not a technology issue.

It requires, as you insightfully said, “being present enough to appreciate the brief moments when the product do settle.”

The more often all the in-progress code and design gets integrated into the whole and released, even if there are bugs, errors, and bumpy UX flows, the more it maintains wholeness.

This is why habits like continuous integration, agile processes, user interviews etc. are so effective but difficult to practice, and why software designers and engineers picked up on Christopher Alexander’s work so readily.

Is it more whole than it was 20 minutes ago? Is it stable enough to be useable and not fall apart? Release it! Take a break, and start again. It’s the patient, repetitive tending of the “gardener designer” you’ve written about.

Another thing to note is the variable of scale. Paintings can be very small or giant murals, software tools can be small like a pocket knife or vast like a construction site.

At a certain size, looking for “doneness” at the largest whole is an exercise in frustration. It’s too big for the human scale to get an intuition about wholeness and balance. I wrote about this a bit more in “No one builds a town".