10. Inches, Ounces, Bits, Dollars—The Budgeted Resource
If a design, particularly a team design, is to have conceptual integrity, one should name the scarce resource explicitly, track it publicly, control it firmly.
What’s the Budgeted Resource?
Within any design, there is at least one scarce resource to be rationed or budgeted. Sometimes there are two or more to be jointly optimized; but most commonly, one is dominant, and others appear chiefly as desiderata or constraints. Economists call this the limiting resource; I prefer to emphasize the necessary designer action: conscious budgeting.1
Although designers often talk as if cost or some performance/cost ratio were the resource to be optimized, that is often not how they act in practice. It follows that if a design, particularly a team design, is to have conceptual integrity, one wants to name the scarce resource explicitly, track it publicly, control it firmly.
Often Not Dollars
Ponder some budgeted critical resources that are not dollars:
• Inches of oceanfront, in a beach house
• Ounces of payload, in a spacecraft—or in a backpack
• Memory bandwidth, in any von Neumann computer architecture
• Nanoseconds of timing tolerance, in a GPS system
• Calendar days, on an asteroid-interception project
• Resident kernel memory space, in OS/360 design
• Program hours, at a conference
• Pages, on a grant proposal or a journal paper
• Power (and stored energy) on a communications satellite
• Heat, in a high-performance chip
• Water, on western farmland
• Student learning hours, in a degree curriculum
• Political power, in an organization’s constitution
• Seconds, even frames, in a film or video
• Hours of access to the track per day, in London Underground engineering and maintenance
• Format bits, in a computer architecture
• Hours or minutes, in a military assault plan
Even Dollars Have Flavors, and Surrogates
Even when cost is in fact to be the budgeted commodity for a design project, cost varieties must be considered. For personal computers, made by the hundreds of millions, manufacturing cost is dominant. For supercomputers, made by the dozens, development cost dominates.
Quite often, designers adopt surrogates for dollars as their budgeted resources. Building architects will do program development, and often schematic design, using square feet as the rationed resource. Computer architects used to use bits of register and of various cache levels as surrogates for chip area.
Surrogates have several advantages: They are usually simpler. One can design with them long before one knows the surrogate/dollar ratio. They are more stable. Using the same surrogate harnesses one’s previous design experiences, even though the surrogate/dollar ratio may be different, or even varying. One knows how many square feet per occupant an auditorium needs.
Surrogates can also lead one astray; the temptation is to use them after they cease being appropriate. Chip designers often thought in terms of area well after wiring length or pin count became the important critical resource.
The Budgeted Resource Can Change
Shifts in technology sometimes change which resource is critical. Therein lie snares for the unwary. As chip densities went up, I/O pins displaced chip area as the limiter on function, hence became the rationed commodity. But power dissipation has now displaced pins as the rationed commodity on many chip designs. Seymour Cray once famously said, “Refrigeration is the key to supercomputer design.”2 Gene Amdahl told me, about the same time, that off-chip capacitance was the speed-limiting commodity in his designs.3
Some think that number of classes has replaced function points as the estimator for software complexity, hence for probable size. Experienced consultants Suzanne and James Robertson, however, say that they find function points still to be the most robust estimator.4 Eoin Woods, an experienced developer, points out:
People want to measure two things: How much value is delivered and how much artefact needs to be produced to deliver it. Function points are good because they try to measure the former, whereas lines of code, number of classes, and so on, are very sensitive to style. One can reduce both of these while increasing delivered value quite easily [reviewer’s comment].
The budgeted resource can change in the middle of a design, just because we get smarter. Operating System/360 (1965) was designed to cover a 16-fold range of computer memory sizes, from 32K bytes (yes, K, not M) up to and beyond 512K. Clearly, some memory space had to be left for the application program, so the resident kernel of the operating system was sorely constrained—to 12K in the tightest case. We were sure that memory space was the constraining “budgeted resource.” We were wrong.
OS/360 was one of the first operating systems that could assume a disk for storing the operating system. Earlier operating systems were tape- or even card-based. Having random-access systems resident wonderfully expanded the function one could build into limited space. “Just read in a chunk from disk.” And everybody in the system design team did—with great frequency: chunks had to be small, to fit the 1K buffer area of the smallest configuration.
One of our wisest developers, Robert Ruthrauff, began early in the OS/360 project to build a performance simulator, and fortunately he got it running early. The first results were horrifying! On our second-fastest computer model (Model 65), our programming system would compile only five Fortran source statements a minute! That day, the project’s budgeted resource switched from memory bytes to disk accesses.5
So What?
If thinking in terms of a budgeted resource is a healthy discipline for a design team, what actions follow as corollaries?
Identify Explicitly
A project manager naturally begins by enumerating all the objectives and constraints. Explicit identification of the budgeted resource should be next. Notice that as defined and discussed, this is usually a resource of the design, not of the design process. For example, skill allocation is always crucial to a design project, but it is not a property of the design itself.
Project schedule may be critical, but it is often the property of the project, not the resulting design. For example, in preparing a competitive proposal against a hard deadline, “We’ll do the best design we can in the time we’ve got.” On the other hand, if designing to divert the asteroid, schedule days become the budgeted resource. Similarly, in a race to be first to market with a totally new product, schedule may become the budgeted resource.
Track Publicly
The whole team needs to know, continually, the current budget for the critical resource. In particular, each sub-team, each team member, must know how many chip milliwatts or transaction-processing disk accesses their part of the design may use, how many they control.
Control Firmly
Whatever the critical resource, the team leader will keep a small personal kitty for late allocation, just as a general keeps some reserves for dispatch to the hottest part of the battle as it develops.6
It is imperative that only one person control budgeting and rebudgeting. Gerry Blaauw did this superbly with bits in the Program Status Word of the System/360 architecture. These were, along with memory bandwidth and bits in instruction formats, the budgeted resources the architects were allocating. His total system overview, his cautious stinginess, his inventiveness of alternatives within the existing architecture, all combined to make a highly efficient architecture.7
Ken Iverson, winner of the Turing Award for his APL language, desired conceptual integrity above all, so he made the number of distinct language concepts the budgeted resource. Countless proposals were made, both within the implementing team and from the using community, for new constructs embodying additional concepts. His total system overview, his cautious stinginess, his inventiveness of solutions within the existing language, all combined to make a highly elegant language.
Marissa Meyer today exerts the same total system overview, the same passion for consistency in design, and the same cautious stinginess in her role as the dragon guarding Google’s look and feel.8
Notes and References
1. Simon [1996], The Sciences of the Artificial, also treats finding the limiting resource as crucial to the design process (143–144).
2. Murray [1997], The Supermen.
3. Personal communication [about 1972].
4. Personal communication [2008].
5. Digitek’s elegant little Fortran compiler (1965) used a very dense, specialized representation for the compiler code itself, so that external storage was not needed. The time lost in decoding this representation interpretatively was gained back tenfold by entirely avoiding the budgeted constraint—disk accesses. Brooks [1969], Automatic Data Processing, Chapter 6.
6. A general planning a battle is a designer in a most serious sense, and one who perhaps more than any other must rapidly revise his design in the face of new facts and constraints.
7. Blaauw [1997], “IBM System/360,” Section 12.4.
8. Holson [2009], “Putting a bolder face on Google.”