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

Planning too much or too little: shaping work at the right altitude

Aspects: effective action (flexible use and revision of procedures) · epistemology (crossing abstraction levels, relating details with the big picture) · problems (messes to manage)

Signals you are in this situation

Section titled “Signals you are in this situation”
  • The plan is a task list nobody believes, or there is no plan at all.
  • Work is estimated to the hour before its shape is known.
  • Nothing ships until everything does.
  • Backlog items from years ago are still marked important.
  • Designers and programmers hand work to each other instead of working one slice together.

The situation

Section titled “The situation”

Soon after Basecamp shipped a version without a calendar, customers started asking for one. The team had built calendars before and knew a proper one takes six months, and they knew from earlier versions that only about a tenth of customers used it. Instead of saying yes or no, they called a customer who had asked, and instead of asking what a calendar should look like they asked when she had wanted one. She had driven to the office in bad traffic to look at a chalkboard wall calendar and see whether a meeting room was free. The problem was not “a calendar” but “let me see free spaces from home”. A read-only two-month grid with a dot per event fit in six weeks, and that is what they built.

Shape Up frames this as a question of altitude. Handing a team a set of wireframes defines too much too early, leaves designers no room, and, counter-intuitively, makes estimation worse, because the hidden complexity of making the interface exactly so is invisible in the mockup. Handing a team “build a calendar view” defines nothing: nobody knows what is in or out, and the project grows to fill whatever time it is given. Both are rational-looking plans. Both fail for the same reason.

The meta-rational perspective

Section titled “The meta-rational perspective”

David Chapman’s account of software management rationalism describes two opposite dysfunctions that share a root. Overcontrol treats architectural and design judgment as a normal management problem, to be fixed by imposing formal representations of the work in advance: detailed processes, diagrams, sign-offs. In the best case the technical leads produce the documents and quietly ignore them; in the worst case the project drowns in rituals describing work that never gets done. The opposite dysfunction is to take the Agile Manifesto’s critique of planning naively and plan nothing, which the Manifesto never proposed; its principles are meta-rational maxims about welcoming change and measuring progress by working software, and they are easily read as permission to under-specify.

Foote and Yoder add the architectural version of the same point. Premature architecture can be more dangerous than none, because unproven structural hypotheses turn into straitjackets that discourage evolution, while an immature architecture lets data and functionality migrate to their natural places as the system is used. That is not an argument against structure. It is an argument that structure has to be imposed at the moment the system has taught you enough to know what structure it needs, and not before.

The meta-rational task, then, is to choose the altitude at which to fix things, and to hold different parts of the work at different altitudes at the same time. Shape Up’s shaped work is rough enough that everyone can see it is unfinished, solved enough that the main elements exist and connect, and bounded enough that the team knows where to stop. Its instruments are the appetite, which fixes time and lets scope vary, so that “good” becomes relative to a constraint rather than an unreachable absolute; the narrowed problem, found by asking what was going wrong rather than what could be built; and the pitch, which packages problem, appetite, solution, rabbit holes, and no-gos together so that the people deciding can judge fit. A backlog is what you get when you refuse to make that judgment: a pile that grows because every idea was accepted at first contact and none was shaped.

Failure path

Section titled “Failure path”
1 Raw idea arrives “customers want a calendar” 2 Say yes, add to backlog commitment before understanding 3 Narrow the problem skipped: “calendar” means everything 4 Wireframe it every detail fixed, then estimated 5 Task lists by role design list, programmer list 6 Build in layers nothing to click until the end 7 Deadline arrives scope grew; cut in a panic “calendar 2.0” goes back on the backlog
How the situation goes wrong when handled purely rationallyHow to read

The idea is accepted the moment it arrives, so a commitment exists before anyone understands it. The problem is never narrowed, so “calendar” means everything a calendar has ever meant. Someone wireframes it, which fixes the details and produces an estimate that hides the complexity. The work is split into task lists by role, so many tasks get done but nothing is finished until the end. When the deadline arrives, scope has grown into the vacuum, and what ships is whatever survived a panicked cut. The leftovers go back on the backlog as version two.

Corrected path

Section titled “Corrected path”
1 Raw idea arrives “interesting, maybe some day” 2 Set the appetite time first, design second grilling: Interviews you round by round until nothing about a plan is left silently assumed.grilling 3 Narrow the problem when did you need this? 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 4 Rough out elements fat-marker, not wireframe wayfinder: Charts work too big for one session as a map of decision tickets with a named destination.wayfinder 5 Find rabbit holes research: Sends a background agent to primary sources and writes cited findings to a file.research prototype: Builds throwaway code that answers one design question.prototype 6 Write the pitch problem, appetite, solution, no-gos to-spec: Synthesises the conversation into a spec and publishes it to the tracker.to-spec 7 Slice and bet vertical slices, not task lists to-tickets: Breaks a spec into tracer-bullet tickets with blocking edges.to-tickets triage: Moves issues through triage states and writes agent-ready briefs.triage not bet on: let it go, no backlog hole with no fix: reshape or shrink
The same path with skills inserted at the break pointsHow to read

The default answer to a raw idea is a soft no that keeps options open. The appetite is set before any design, so the design has a constraint to be good relative to. The problem is narrowed by asking when the need arose, not what the solution should be, and when that knowledge belongs to a customer or another department it is fetched from them. Elements are roughed out at fat-marker resolution on a map that admits where the fog is. Rabbit holes are hunted with reading and disposable code before anything is committed. The pitch is written only when problem, appetite, and solution fit together, and it is either bet on and sliced vertically or let go without a backlog to hold it.

Skills for this situation

Section titled “Skills for this situation”
Skill When to invoke it here What it changes Example
grilling (via /grill-me) At first contact with the raw idea, to set the appetite and narrow the problem before anyone sketches a solution. The interview asks how much time the idea is worth, what specifically was going wrong when it arose, and what is out of bounds. It refuses “calendar 2.0” grab-bags until a single use case is named. /grill-me the request for a calendar: what is the appetite and what was going wrong?
to-questionnaire When the narrowing question can only be answered by the person who had the need. Produces the “when did you want this?” questions for one named customer or colleague, so the baseline story comes from them rather than being imagined. /to-questionnaire for the customer who asked for a calendar
wayfinder When the shaped work is larger than one session and has visible fog. The map holds the elements at low resolution and the tickets hold the detail, which is the intermediate altitude Shape Up asks for. The fog is written down as unspecified rather than being filled in by guesswork. /wayfinder: destination is a pitch for seeing free meeting slots
research and prototype While hunting rabbit holes, before the pitch. Reading settles the questions that documentation can answer; a throwaway prototype settles the ones only an artifact can. A hole that neither can close is patched by a decision or fenced off as a no-go. /prototype the two-month dot grid with real event data
to-spec When problem, appetite, and solution fit together and the holes are patched. The spec carries the five pitch ingredients: problem as a specific story, appetite, solution sketch, rabbit holes, and no-gos. It is a bet to evaluate, not a task list to execute. /to-spec
to-tickets Once the bet is placed. Breaks the spec into tracer-bullet slices, each of which integrates front and back end so that something is really done early, rather than lists per role that come together at the eleventh hour. /to-tickets from issue #30, vertical slices, core and novel first
triage For ideas that were not bet on, and for anything that arrives during the cycle. Keeps the tracker from becoming a backlog: ideas are categorised, sent for grilling if they warrant it, and closed if they do not, on the understanding that important ideas come back. /triage

Sources

Section titled “Sources”