2019-08-13 21:15

When Is Software Ready?

Is software ready when it's (mostly) bug free? When all promised features are ready? When it offers enough commercial value to be put into use for instance when it’s able to generate revenue? When all the boxes are ticked on a Definition of Done list? When the schedule says so? Or the boss?

The software industry has wound up in a strange place. When is a doctor ready with an operation? A physicist with a mathematical model? Or an airplane engineer diagnosing an engine problem? The universal answer is "it's ready when she says it's ready". Why do we, generally speaking, accept this answer from people in these occupations, but not from software professionals?

Let's explore a list of possible reasons:

Composability fallacy

Even non-developers know that software can be built using a mix of new and existing components. While developers know implementing an existing component in the form of a library or API has its own set of challenges, the availability of components has decreased the perceived complexity of building software. But perhaps the (perceived) benefits of using existing software outweigh the actual benefits?

Similarity fallacy

Chances are that what you are building is not unique. Most people in the team will realize this, management knows it, as well as the customer. Does this introduce the fallacious argument "since it's already built by company X and Y it can't be that hard"? Since no one knows how much effort was needed–and since you can’t benefit from their experience–you should not use this argument,

Misjudging complexity

This is the most commonly heard reason among developers ("if only they knew how complex this is"). A great example of misjudging complexity is translating a website to a second language. For a non-developer the problem is simply "make a copy of the site and ask a translator to translate all the words". But developers know that making software multilingual is probably a multi-week effort.

Dogmatic scheduling

Companies, understandably, schedule meetings, payments, hirings, deliveries, procurements, et cetera. This is convenient, plannable, and professional. It's only logical (albeit incorrect) that people assume software development, being a cog in the big machine, can follow the exact same scheduling process like any other part of the business. Don't get us wrong, we think it's actually possible to achieve a reasonable degree of planning accuracy, provided the scope is small and well-defined, but "reasonable" does not fit everyone's definition of planning accuracy.

These reasons, put together, may lead to a conflicting notion of the state of readiness of software, or how quick readiness can be achieved during the last phase of development.

What can you do to align development teams, management, and customers on acceptance criteria?

  • Compile a list of checks (i.e. release criteria) that the software must pass. The wording should be precise and preferably non-technical. Ensure each check covers a single feature or even better, a specific element of a feature.
  • Make sure all stakeholders agree, beforehand, that this checklist to a large degree defines the state of readiness.
  • Don't wait till the very last moment to apply this checklist. Instead, use it on a daily basis during the development phase to assess how far a project is. Note that a project's timeline is not a straight vector, instead it's more like a bell curve (what Basecamp calls a Hill Chart) so don't fret if progress seems slow in the beginning.
  • Developers should take time to carefully explain non-obvious complexity. Management and customers should explain which business priorities drove the decision to create this software in the first place, enabling developers to prioritize their work. It's not enough to do this during a one-time kick-off meeting. Transferring knowledge takes time, schedule follow-up meetings to keep discussing points of view, and especially assumptions, from both sides.


The decision to release software should be based on mutually agreed criteria. Don't argue about "why are features X and Y not ready?", instead discuss "what is needed to complete checklist items #11, #23, and #74". In this way you keep the readiness discussion practical and devoid of emotion.

Permalink — Comments or kudos? Find me on Twitter.

Are you a project or product manager? Ship better software with Releasewise!