Programming module: high-yield pitfalls and confusions

One-line orientation

A roll-up of small, high-frequency Programming traps that don’t each merit a full card — who owns programming, what the architect’s assist scope covers, and one-line reminders of the module’s most-confused pairs.

Key points

• Programming is the Owner’s responsibility — B101 §5.1 requires the owner to provide a written program; the architect or a consultant assists. When the architect develops the program, it is generally a separately compensated service rather than part of the standard Basic Services.
• Architect’s typical programming-assist scope: net-to-gross ratios, cost per square foot, site requirements, and mechanical heating or cooling.
• Bubble before block: the bubble diagram graphically represents adjacencies; the block diagram comes last and adds shapes and sizes. (Full card exists — this is the one-line reminder.)
• Measurement lines: GBA to the outside face of exterior walls; Usable to the inside face. The face you measure to is the trap.
• Gross-up direction: GBA = net area ÷ efficiency, never ×. A 0.80 efficiency makes the building bigger than the net program, not smaller.
• Three levels, never merged: goal (what/why) → programmatic concept (how, abstract) → design solution (what to build). Programming stops short of the third.
• Programming defines the problem before Schematic Design begins solving it. Later program revisions may still occur if project needs or resources change.

Confusions / comparison

Confusion	One side	The other side
Who programs	Owner — responsible for providing the program (B101 §5.1)	Architect — assists; developing it = Supplemental/Additional Service
Bubble vs block diagram	Bubble — adjacencies only, no geometry	Block — last step; adds shapes and sizes
GBA vs Usable measurement	GBA — outside face of exterior walls	Usable — inside face of exterior walls
Net → gross math	Divide by efficiency (grosses up)	Multiplying — wrong direction
Goal vs concept	Goal — what the client wants and why	Concept — how, in abstract performance terms
Programming vs SD	Programming — defines the problem, before design	SD — begins solving it

Related

→ prog-programming-vs-design (this module): the full phase sequence and problem-seeking framing · prog-criteria-to-block-diagram (this module): the 4-step order behind the bubble/block reminder · prog-area-types (this module): full measurement rules · prog-efficiency-net-to-gross (this module): the efficiency math · pp-basic-vs-additional-services (ProPractice module): programming as an Additional Service under B101.