On the meaning of Done

In software companies there’s always a debate about the meaning of done. This isn’t (just) because software engineers can be pedantic nerds (I say this with love and affection, because pedantic nerdery is often a required attribute for good engineers). It can be because the business needs/wants to track progress metrics for internal reporting purposes, the dreaded KPIs, and so on.

Consider what happens when the business receives a bug report from a customer. The business wants to minimise the time taken for that customer to receive a fix: done in this scenario means “customer has fix” and the business will probably want to see graphs showing the time taken for bugs to move from initial report to done and whether that time is getting shorter or longer.

From the perspective of the engineer fixing the bug, things look different. The engineer doesn’t want to be held accountable for externalities — those things not under their control. For example:

The time between “customer reports bug” and “engineer told to fix bug”. This period of time belongs to people higher up the food chain, who prioritise and schedule the work.
The time between “internal build confirms correct fix” and “customer has fix”. This period of time can belong to many people, including those same higher-ups, and other engineers in charge of deploying/distributing fixes, and even senior management instituting freezes to avoid disruption at known times of heavy load such as holiday periods.

The engineer’s idea of done is “smaller than” the business’s idea of done.

Unless you work in software you would not believe how many meetings I’ve been in over the years in which these distinctions have been discussed and dissected. It’s because both are valid metrics, and people are trying to hammer contradictory definitions into the same word, done.

In a status meeting, if someone asks the innocent question “Is that bugfix done?” a perfectly acceptable response might be “Can you define what you mean by done?”

Some teams distinguish the two concepts using done and done done (yes, really). It works — as long as everyone understands the differences and can pick up the doubled word (engineers with English as a second language don’t necessarily spot this).

Other teams ban the word done and use more explicit wording, like “fix ready for production” versus “fix in production”, or a hundred other variations. For me this is generally the better approach, but still needs careful wording and education inside and outside a team to make sure all the stakeholders (ugh) understand the nuances.

Anyway, all this preamble is simply to say that Unstable Orbits is done.

Can you define what you mean by done?

I’m glad you asked!

I’ve completed what I believe is my final editing/proofreading pass. The only content changes anticipated now should be extremely minor, as a result of issues found by ARC readers, or during the print layout process.

What happens next?

Many things.

I’m currently working on marketing materials that will trickle out on various platforms from the beginning of June. (As well as Instagram and Facebook I’m also now on TikTok, and I have a YouTube channel.)

I’ll soon be preparing ARC ebook editions — Advance Review Copies — for distribution to the people who’ve kindly signed up to read and post early reviews. Those will likely go out on June 1.

Then I’ll be creating the print version of the book. This shouldn’t take long — under a day, I expect.

Release is still planned for June 15: on Amazon (ebook and paperback), Kobo (including Kobo Plus) and Apple Books. The Unstable Orbits book page has all the links.

At that point Unstable Orbits will officially be done done — and all I’ll do is marketing.

Until I receive bug reports…