Skip to content
Meta-Rational Software Development with Engineering Skills for AI

Purposes keep changing and belong to the whole context, not the requester

Aspects: purposiveness · breadth of considerations · contingencies

Signals you are in this situation

Section titled “Signals you are in this situation”
  • The same request means different things to two departments.
  • Something shipped last quarter is being used for a purpose nobody planned.
  • The backlog grows faster than it shrinks and nobody can rank it.
  • The stated goal has not been revisited since the project started.
  • Users export to spreadsheets to do what the tool was supposed to do.

The situation

Section titled “The situation”

A paper products company adapted a wartime gas-mask filter into a soft tissue and sold it for removing cosmetics. Customers, finding the tissue within reach when they needed to blow their noses, gave it a second purpose that nobody in the company had planned. The company only learned about that use, and started advertising it, years after the product first went on sale. The purpose that made the product what it is today was discovered and created by its users, after the fact, and outside the room where the requirements had been decided.

Software behaves the same way. Einar Høst, writing about an online news service, points out that the problem his team is solving is shaped by shifts in how the public consumes media, by what large platforms do, and by forces that arrive from unexpected directions, so that the problem is always partly under negotiation. Chris Krycho makes the complementary point about spreadsheets: people do things with them that their makers never imagined, and that flexibility is the reason spreadsheets survive. A software project that treats its purposes as a list gathered once, from the people with the most organisational weight, has arranged to be wrong in three separate ways.

The meta-rational perspective

Section titled “The meta-rational perspective”

Rationality needs purposes to be fixed, so that a Problem can be stated and a Solution checked against it. Chapman’s account of purpose runs the other way. Purposes are interactional opportunities that live in a broad context: the immediate situation, plus everything relevant to acting in it, including people, institutions, and events at some distance. They are found bottom-up, by abstracting from recurring moments, and that abstraction always loses some precision. They are as much created as discovered: a conversation between a developer and a warehouse manager can bring a purpose into existence that neither had before. And they do not hold still. They emerge, evolve, and dissolve as circumstances, technology, and the people involved change.

Three consequences follow for a project. First, the holder of a purpose is the whole context, not the requester. The people who understand different parts of the mess each hold a piece, which is why the Agile principles insist that business people and developers work together daily throughout, not at a kickoff. Second, formalising purposes is still necessary, because software is formal, but it should happen only once an informal understanding is adequate, only to the extent needed to guide construction, and with continuing awareness of where the formalisation distorts what it describes. Third, since purposes keep changing, most of a serious system’s cost and most of its value arrive after the first release, as people find uses for it. The Agile principles call this welcoming changing requirements even late in development; Chapman calls the question of what a situation needs permanently open.

The failure is not that requirements changed. It is that the process was built to prevent them from changing, and so could only register change as a defect.

Failure path

Section titled “Failure path”
1 Gather purposes once kickoff workshop, stakeholder list 2 Freeze them signed requirements document 3 Prioritise by clout loudest voice wins 4 Build the whole list nothing ships until everything does 5 Ship exactly what was asked for 6 Users improvise unexpected uses, filed as misuse 7 The business moves requirements stale on arrival change request: freeze a new list the same way
How the situation goes wrong when handled purely rationallyHow to read

Purposes are collected once, at a workshop, from whoever was invited. The list is frozen by sign-off, and priority goes to the people with the most clout rather than the most understanding. Nothing ships until the whole list is done. When users improvise new uses, the improvisation is treated as misuse. When the business moves, the frozen list is simply out of date, and the only available response is a change request that freezes a new list the same way.

Corrected path

Section titled “Corrected path”
1 Name a destination scope, not a list wayfinder: Charts work too big for one session as a map of decision tickets with a named destination.wayfinder 2 Explore the mess every affected role grilling: Interviews you round by round until nothing about a plan is left silently assumed.grilling to-questionnaire: Turns a question you cannot answer into a questionnaire for the person who can.to-questionnaire 3 Record purposes as decisions, dated domain-modeling: Challenges overloaded terms and writes the glossary and decision records.domain-modeling ADRs: Architecture decision records: dated, reasoned decisions kept in docs/adr/.ADRs 4 Build one slice end to end, early prototype: Builds throwaway code that answers one design question.prototype implement: Implements a spec or tickets test-first at agreed seams.implement 5 Ship it weeks, not quarters implement: Implements a spec or tickets test-first at agreed seams.implement 6 Watch it in use improvised uses are evidence context-fit check: A third review question: what did building this reveal about the request itself?context-fit check 7 Move the destination when the business moves wayfinder: Charts work too big for one session as a map of decision tickets with a named destination.wayfinder ADRs: Architecture decision records: dated, reasoned decisions kept in docs/adr/.ADRs the context changed: revise the destination, not just the list a new use appeared: record it as a purpose
The same path with skills inserted at the break pointsHow to read

The shape is unchanged. What differs is that the project names a destination rather than a list, explores the context with everyone affected, and records purposes as dated decisions that are expected to be revised. One slice ships early so that use, the best source of purpose information, starts sooner. The two loops make the changes explicit: an improvised use is recorded as a purpose, and a change in the business revises the destination itself rather than being squeezed through the old plan.

Skills for this situation

Section titled “Skills for this situation”
Skill When to invoke it here What it changes Example
wayfinder At the start, when the work is larger than one session and its shape is not yet visible. Replaces the requirements list with a destination that governs scope, and a map of open decisions on the issue tracker. The destination is a decision, so it can be revised when the context moves. /wayfinder replace the eleven fixed reports with something finance can use for questions we have not heard yet
grilling (via /grill-me) Whenever a purpose is stated as a fact rather than as a decision. Asks what this purpose is for, who else it affects, and what would change if it were dropped, until the purpose is located in the context rather than in one person’s head. /grill-me the purpose behind the barcode scanner request
to-questionnaire When a purpose is held by a role that is not in the room. Fetches the missing piece from the person who has it, and makes the send explicit: who, and what you need back. /to-questionnaire for the loading dock supervisor: what do you need to know about a delivery before you accept it?
domain-modeling and ADRs Each time a purpose is settled, even provisionally. Records the purpose and the reason as a dated decision, so that when it changes the project can see what changed and why, instead of rediscovering it. /domain-modeling record the decision to serve ad-hoc reporting rather than fixed reports
prototype then implement As early as a slice can be made runnable. Puts something in front of the people whose purposes are still forming. Their reactions are purpose information the workshop could not have produced. /prototype a report builder where an analyst picks the fields to aggregate
code-review, with a context-fit question After each shipped slice. The skill checks standards and spec. Add the question the skill does not ask: what new uses or purposes did this slice reveal? Answers go back to step 3, not into a bug list. /code-review against main, then: what did people do with this that we did not plan for?

Sources

Section titled “Sources”