Why the Circular Specification Problem and the Observer Effect Are Distinct

Recent posts
Why the Circular Specification Problem and the Observer Effect Are Distinct
What Factors Explain the Nature of Software?
Some Reflections on Writing Unix Daemons
Faster Shell Startup With Shell Switching
Choosing What To Read
Debugging A Failing Hotkey
How Often Should We Sharpen Our Tools?
Four Kinds of Optimisation
Minor Advances in Knowledge Are Still a Worthwhile Goal
How Hard is it to Adapt a Memory Allocator to CHERI?

Blog archive

Following “What Factors Explain the Nature of Software?”, a number of people have asked me: “aren’t the circular specification problem and the observer effect the same thing?” I take the blame for not making this clearer previously. In this post, as recompense, I’m going to explicitly explain why I believe these two factors must be considered distinct.

As a quick reminder, in my previous post I defined a triad of factors that I believe go a long way to explaining what the nature of software is:

  1. Software occupies a liminal state between the constraints of the physical world and an anything-goes fantasy world. We frequently mistake the constraints that software faces.

  2. Our ability to specify what a given piece of software should be is limited by the circular specification problem. We nearly always have to fully build the software in order to know precisely what we want it to be.

  3. Software is subject to the observer effect. The act of seeing the software in action changes what we – or more often others – think the software should be, sometimes radically.

As I’ve written them above, many people – not unreasonably – have read the last two factors as if they’re different ways of saying “we keep changing our mind about what the software should be while we’re building it”. Indeed, at a sufficiently high level, that’s correct!

However, there’s a reason why experience has shown me that these two factors must be considered separately. In part it has to do with who is changing what the software should be. Simplifying slightly:

  • The circular specification problem is caused by the software’s designers and programmers [1] not knowing what exactly what the software they were tasked with building should be.
  • The observer effect is caused by users realising either that: they can use the software in a way that wasn’t anticipated; or they can’t use it in a way that they want to.

In other words, the circular specification problem is caused by “internal” factors in the development process while the observer effect is caused by “external” factors.

If “who” was the only differentiator between the two factors, they probably wouldn’t be worth considering separately. But in this case “who” is a proxy for something deeper. One obvious distinction is that early stage problems in software development often result from the circular specification problem, but later stage problems often result from the observer effect [2].

The more profound reason for the distinction is that, in my experience, many organisations consider at most one of the circular specification problem or observer effect — normally just the former.

I have seen many instances of huge effort being spent developing software without anyone taking the time to consult with users whether they’re building the right thing. In those cases where the time has been taken to consult with users, it is unfortunately common that much or all of the feedback – normally the negative part – is ignored on the basis that users are too ill-informed to understand the grand vision for the software being built.

Pretending that the observer effect doesn’t exist is a short-term win, but it nearly always comes with significant long-term costs [3]. At best, it causes unnecessary churn when users highlight unexpected opportunities late in the day. At worst, it causes the demise of the software when unexpected problems are discovered so late that fixing them can amount to a virtually total rewrite of the software.

Ultimately, when we fail to consider the circular specification problem and observer effect as distinct factors in the nature of software, we set ourselves up for problems that could have been prevented relatively easily. That’s why my experience has shown me that these two factors are so important that they must be considered as distinct.

2024-05-31 10:10 Older
If you’d like updates on new blog posts: follow me on Mastodon or Twitter; or subscribe to the RSS feed; or subscribe to email updates:

Footnotes

[1]

In the previous post I explained why a hard split between “designers” and “programmers” rarely makes sense, but that doesn’t matter too much from this post’s perspective.

In the previous post I explained why a hard split between “designers” and “programmers” rarely makes sense, but that doesn’t matter too much from this post’s perspective.

[2]

As the previous post showed, software development must by definition be an iterative process. However, it is clearly the case that there is a different balance between the factors we’re talking about in the early vs. later stages of software development.

As the previous post showed, software development must by definition be an iterative process. However, it is clearly the case that there is a different balance between the factors we’re talking about in the early vs. later stages of software development.

[3]

Although less common, I have occasionally seen people think that continually asking users what they think of the software under construction absolves them from any internal thought about design or specification, leading to endless churn.

Although less common, I have occasionally seen people think that continually asking users what they think of the software under construction absolves them from any internal thought about design or specification, leading to endless churn.

Comments



(optional)
(used only to verify your comment: it is not displayed)