Norma's car must fit

The software this part builds is real. Browse the project, or download and run it, at any point. You don't have to wait for the software chapters. And the running score of what the bench has and has not proved lives in The Lab Ledger.

The old garage had room to absorb almost any answer.

Two bays, a workshop area, long benches, cabinets, shelving, and basement overflow. The reloading bench was purpose-built, fifteen years in service, with a wall to itself. Lawn equipment spread down another wall. A stalled project could keep its staging area because nothing nearby needed the space back.

It worked. Tools were findable. Ammunition was loaded. Nothing in the room demanded immediate repair.

Then we moved.

The new garage was smaller and shared. It had to hold a workshop, lawn equipment, household storage, a freezer, a teenager's bicycle, and a reloading station. It already had one continuous job.

Norma's car must fit.

Not technically fit. She pulls in, opens the door, gets out, and walks to the house without turning sideways around somebody else's project. Every night.

That requirement outranked the reloading bench before the bench entered the building.

Done, defined outside the project

On moving day, the temptation was to call the garage done when it was organized. That feeling had no boundary. There was always another box, shelf, or tool without a home.

The immediate capability was smaller and sharper: restore enough open floor for the car. The boxes not yet sorted did not count against that outcome. The clear concrete did.

Done became observable from the doorway.

Before: abundant space let projects and unresolved placement decisions coexist.

After: the car and the reloading station pass the containing-system test together.

Write the definition in one sentence:

The first garage slice is done when Norma can park inside and the household can move safely around the car without dismantling another working area.

Three things are inside that sentence:

• a user who receives the capability;
• an action the system must support;
• an obligation that must remain true around it.

The reloading station cannot grade itself against those criteria. A perfect bench that blocks the car is a failed component inside the system that actually matters.

Draw one system outward

Start with the proposed project in the center and draw the system containing it:

HOUSEHOLD
   |
   v
GARAGE
   +-> parking
   +-> safe circulation
   +-> household storage
   +-> yard-maintenance capability
   +-> workshop
   |      |
   |      +-> reloading station
   |
   +-> freezer and utilities

The reloading station is one tenant. The garage is the landlord. The household is the containing system that decides whether the garage is useful.

The owner is not the designer

Norma owns the parking constraint. She does not own the bench coordinates. She can say the car door must open and the path to the house must remain clear without deciding where the Dillon sits. The need is hers. The mechanism is a design decision.

Now add the other constraint owners:

A stakeholder request may contain a need, a proposed solution, or both. The design still has to discover which is load-bearing.

That distinction prevents two failures: ignoring the person who bears the cost, and treating every suggested implementation as an immutable requirement.

Ownership names what must remain true. Design decides how.

Walk the containing system

I mocked up an early layout and asked Norma to walk it.

My arrangement worked for the operator at the bench. It gave the presses room and made the storage plausible. Norma walked the same floor and found problems for parking and movement because she was evaluating a different system.

The bench was locally correct. The garage with the bench inside it was not.

A subsystem that optimizes itself against the containing system is wrong in a way it cannot see from inside.

The walkthrough did not make every preference a requirement. It put the actual stakeholders in contact with a full-scale representation while change was cheap. Their movement produced evidence the bench plan could not produce alone.

The freezer outlet told the same story later. An extension cord temporarily bridged a broken receptacle. As daily use returned, the cord's path became the path Norma and Sean used. The workaround had not changed. Its containing system had, and the safety cost rose. Ship a complete thought returns to the repair as a complete shipped capability.

Name the level of work

The same garage can be discussed at four levels:

A task can finish while the problem remains. An epic can succeed locally and damage the initiative. Confusing the levels creates opposite mistakes: an evening task receives months of architecture ceremony, or a load-bearing initiative decision gets made as an evening impulse.

Name the level before asking what done means. The table is an orientation tool, not a requirement to create four project-management artifacts for every change.

The old bench was not bad

The old reloading bench did not move to the new garage. It was too large for the new pairing of workshop and parking.

That outcome does not make the bench a fifteen-year mistake. It was proven in the old garage against the old system's requirements. More capacity let subsystems remain independent and let unresolved placement costs stay cheap. The new garage made those systems negotiate for shared surface and movement.

"Proven" was never a property of the bench alone. It described the bench in an environment.

This matters in software. A legacy component may be fit for the traffic, team, data, and risk model that shaped it. A migration can make it wrong without making its original authors foolish. Preserve the old contract before declaring the old design defective.

Constraints expose costs. They do not retroactively create them, and they do not prove every prior choice was debt.

Define your containing-system test

Choose a subsystem you are about to build or change. Complete two artifacts.

First, one sentence:

This work is done when ________ can ________ while ________ remains true.

Then the sketch:

Ask:

1. Who can declare the subsystem successful from outside it?
2. What must remain true that the subsystem does not own?
3. Which stakeholder statement is a need, and which part is a proposed implementation?
4. At what level are you working: problem, initiative, epic, or task?
5. Could the component pass its own tests while the containing system fails?

That final question is the beginning of an outer acceptance test. The exact software test waits until the system's parts and message flow are visible.

Where to stop going outward

Every system sits inside another system. The garage sits inside the household, which sits inside a neighborhood, power grid, law, and economy. The exercise is not an infinite regress.

Go outward until the obligations that can invalidate the proposed work are in view and their owners can be named. For this build, household use, safety, parking, utilities, supply, and the range matter. Municipal traffic planning does not change the next bench decision.

The containing system defines success. It does not answer how the reloading station should be built. That is the next chapter's job: draw the parts and connections before touching placement or code.