Sharing is no panacea

From Chapter 3: The Surgical Team

Excerpt
Absolutely vital to Mills's concept is the transformation of programming "from private art to public practice" by making all the computer runs visible to all team members and identifying all programs and data as team property, not private property. (p. 32)

From You and Your Research¹

[Newton] said, "If I have seen further than others, it is because I've stood on the shoulders of giants." These days we stand on each other's feet!²— Richard Hamming

Brooks demands "public practice" because hiding code impedes communication. There is great merit in the suggestion because many development problems stem from the lack of information about the evolving design. In fact, Brooks suggests that the team include a full-time, "Program Clerk" whose primary task is to keep the code in an open library where it can be seen by all team members.

That was then before Source Control Systems made sharing code routine. But code sharing is not the paradise Brooks envisioned. Like an ice cream-based weight-loss cure, the arrival of effortless sharing is wonderful in theory, but too good to be true.

Why? First of all sharing qua sharing is no panacea. What good is there in sharing artifacts that are unintelligible?

The current generation of programming technologies can make code very hard to understand—much harder than 40 years ago. If a programmer uses object-oriented inheritance, generic programing, aspect-oriented programming or dynamic binding, the actual behavior of the program may not be apparent by just looking at a few source code files. If you find yourself trying to grok a non-trivial program, chances are good that you'll be studying the interaction of code in a few dozens of source files, pondering hundreds of pages of cryptic web docs, and spending a few weeks of runtime debugging in order to really understand what that the code is doing.

Brooks recognized most code is not built to be used or understood by other programmers. He explained that if code is intended to be used by others, the development costs may jump by an order of magnitude. The multiplier depends on the type of system product being built. Here's how he classifies those different product types:

Brooks'software product classification

Brooks' breakdown of of software  product types
(from page 5, Mythical Man-Month )

1. A Program
   • The simplest of the product types.
   • Built to be run by the programmer who wrote the program—typically a domain expert.
   • "Commonly produced in a garage."
   • Vast majority of products developed to support NASA missions.
2. A Programming System
   • Collection of interacting programs that work together.
   • Assemblage consists of an entire facility.
   • Requires careful control of interfaces.
   • So long as the interfaces are controlled, the system will work without code sharing.
   • Brooks estimates the cost of a 'Programming System' is 3 times as much as just 'A Program.' However, the cost grows geometrically with the number of interacting programs.
   • Grows brittle with age. The system gets brittle as it ages; changes to one program may break many others.(see Maintenance Mindset)
   • NASA ground systems are 'Programming Systems.' Most are several decades old, brittle, antiquated and very expensive to maintain.
3. A Programming Product
   • Intended to be fixed and used by anyone.
   • Written in a generalizable fashion.
   • Well documented.
   • Includes effective set of test programs.
   • Works on many different operating environments and with different data sets.
   • Costs 3 times as much as just 'A Program.'
   • Typical of a commercial product. For financial and cultural reasons, NASA does not produce programming products.
4. A Programming Systems Product
   • Combined capabilities of the 'programming system and the 'Programming Product.'
   • Today a 'Programming Systems Product' is called a framework.
   • A 'Programming Systems Product' is cost 9 times as much as a 'Program.' (Ouch!)

Aside from the significant increase in the cost of building a product that's intended to be shared, there are other reasons why sharing is no cure all. Consider the plight of the poor programmer:

• Programmers work in an engineering culture which is intolerant of errors.
• Any non-trivial program will have bugs.
• A programmer's code can be broken by the work of another programmer. That 'other' programmer could work on the same team or another team.
• Broken code has consequences. It often creates a lot of extra work that may threaten the schedule.
• Programmers tend to delay exposing a flaw in their own code as long as possible because in most cases it will be fixed in time. The interim can be nerve wracking.
• Programmers are quick to expose a flaw in someone else's code because a quick fix may help with the assignment at hand or because it helps buy more coding time.
• It is often difficult to identify who was responsible for a specific break.
• The specific cause of a breakage is seldom black and white. In a large bureaucracy, like NASA, there can be political consequences for the programmer or programming team considered the offender.

By and large, programmers are a very bright bunch who quickly learn how to protect themselves. One of the best methods of self defense is a good offense. This especially true when an harried manager must rely on his 'go-to' programmer for an appraisal of coding progress and any potential threat to his primary concerns: cost and schedule.

Cultivating a manager's trust is an art; but not necessarily a Machiavellian one. Top-notch programmers are a highly-competitive, self-confident lot.³ They know how to inspire confidence.

During the years I worked on development projects I came to recognized a few traits common to the most talented coders:

• They have a better command of programming languages and thoroughly understand the operation of the compiler and/or the interpreter.
• They are great debuggers. Parsing a 50-line output from stderr is a piece of cake.
• They have an uncanny mastery of multi-threaded programming which by any account is an arcane art.
• The have the ability to grasp the long-term consequences of code organization and data structure.
• They are often highly critical of other programmers and are adept at finding fault.
• They believe they can do most any job and do it better than it was done by the last guy.

Would you want to share your code with someone like that?! Isn't it reasonable ask why anyone would want to make it easy for an outsider to erode the confidence of upper management. Is it any wonder that teams are reluctant to share?⁴

This reluctance to share is standard practice among flight software teams. It doesn't matter if you have every imagined credential, you will not get access to the code unless you are on that flight software team.

So happens that government-funded projects are required by law to share the code with others doing government work.⁵ It is illegal to withhold the code. Yet, in common practice, it is common for the project to withhold code. No one in the project complains. It's a very effective way to keep the flight software from the prying eyes of engineers who might expose fundamental design flaws.

Don't get me wrong. Code sharing is good and much better than keeping it private. However, it's not enough to simply make it available. It must be made available in a form that can be readily understood. But, intelligibility costs and THAT is the real challenge. How do we affordably create programs for a complex system with code that can be readily understood? This is, and has been, an area of active research. Progress has been very slow. We have a long way to go.

On the other hand, competition among top-notch programmers and programming teams will always be intense. Especially in the space business where government funding is a zero-sum game. So, if you share code, stay alert. Someone might be looking for a good pair of feet to stand on.

---

^1. Hamming. R. "You and Your Research." Transcription of the Bell Communications Research Colloquium Seminar 7 March 1986. J. F. Kaiser, Bell Communications Research.
^2. A another version of this quote, "Physicist make progress by standing on one another's shoulders, Programmers make progress by standing on one another's feet." is often attributed to Watts Humphrey.
^3. I never considered myself to better than a middling programmer.
^4. There's an interestingly sharp contrast with unfunded open-source development where programmers are eager to share. The competition for funding makes all the difference because funds can't be shared without a cost.
^5. The code can be shared with any business or institution doing government work under a government-use license (Title 37: Patents, Trademarks, and Copyrights PART 404—LICENSING OF GOVERNMENT-OWNED INVENTIONS §404.4 Authority to grant licenses.). No license is required when sharing occurs for work that being done under the same task order.

Picking the Archetypes for the Surgical Team

From Chapter 3: The Surgical Team

Excerpt
...each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.(p. 32)

From The Good Soldier Švejk¹

Excerpt
When Švejk subsequently described life in the lunatic asylum, he did so in exceptionally eulogistic terms: 'I really don't know why those loonies get so angry when they're kept there. You can crawl naked on the floor, howl like a jackal, rage and bite. If anyone did this anywhere on the promenade people would be astonished, but there it's the most common or garden thing to do. There's a freedom there which not even Socialists have ever dreamed of.―Opening sentences of Chapter 4,

At the beginning of chapter 3, Brooks argues convincingly that you can not do a big job with a small team. He explains that when the team is big, a raft of inefficiencies are introduced. In fact, unless care is taken, the inefficiencies will soon outweigh, and even nullify, the added productivity that motivated hiring additional staff in the first place.

The large team problem is relevant to the space biz because developing a space system is an inherently large job. (see Small is beautiful, but not applicable)

Brooks recommends a solution that was originally proposed by Harlan Mills². During the 70's and 80's, Dr. Mills is one most influential figures in computer science. Among other things, he was chairman the NSF Computer Science Research Panel, editor of IEEE Transactions in software Engineering, governor of the IEEE Computer Society, chairman of the Air Force Computer Science Panel and an IBM Fellow. In addition to these most impressive credentials, Dr. Mills was the originator of the Cleanroom software development process. By all accounts he was a true visionary.

Mills suggests that each part of a job be assigned to a team that's organized like a surgical team.³ This team would be organized according to the driving principle that there be "well differentiated and specialize roles."

Here's a rehearsal of the Mills/Brooks surgical team roles with a few observations of how they play out in NASA.

The Surgical Team

Chief Programmer

In keeping with the surgical team metaphor, Brooks calls the chief programmer the surgeon. The surgeon is responsible for the design. She or he also codes, tests and writes the documentation. On top of that, the chief is also responsible for code management and process tools.⁴

 

Brooks recommends that the chief have at least 10 years in the saddle and plenty of systems and application knowledge. He doesn't mention that this doyen will need to have the endurance of a sled dog because he or she will be facing the prospect of a 100 hour work week.

Copilot

Number 2 on the surgical team is the co-pilot (the surgical team has lifted off.) The co-pilot is the chief programmer's "alter ego." He or she shares the same responsibilities and skills as the chief. However the co-pilot's responsibility is restricted to that of a sidekick, "thinker discussant" who knows all the code and, maybe even, writes some. In some cases the co-pilot serves with plenipotentiary powers when the chief is otherwise occupied. Finally the co-pilot is a hedge against any rogue bus that might flatten the chief.

 

Brooks suggests the co-pilot need not be as experienced as the chief. He doesn't mention that the co-pilot will most likely be a cypher since a dissenting voice in NASA is likely to be traded to another team.

Administrator

The administrator handles the money" and other duties that make up 95% of the typical management responsibilities found in a large bureaucracy. But, Brooks is emphatic, the "surgeon is boss."

 

Brooks skips lightly over the what it means to handle the money. If he means writing proposals, writing budgets, allocating funds, hiring staff, and lobbying with funding sources, he's described a full time role that preempts any technical work. What's more he's allocated the source of all political power to the administrator, including the ability to hire a new surgeon. Perhaps this role should really be called manager.

Editor

Brooks recognizes that engineering team must document how the system is built and how it should be used. For unity of conception, many of these documents must be written by the chief, who is one horrendously busy person. Hence, the editor is needed to gather the recorded wisdoms of the chief and turn them into a thing of beauty and devotion.

Two secretaries

In Brooks' world of the 1970's, documents were not generated automatically. Someone had to type them. As a practical matter, he suggests that the editor and the administrator get secretaries.

 

Those were the days. On my last job at NASA, a secretary (now called an administrator) was shared by 20 engineers. They were our experts on the bureaucracy; they instructed us on how we needed to complete those endless administrative tasks. And while a trip to the secretary usually resulted in another work assignment, their instruction was necessary for survival in the maze of institutional rules.

Program clerk

Any programming effort produces a mountain of artifacts. Managing all the programming products is not for the faint-hearted. Consequently Brooks adds a Program clerk to his team. Nowadays, the job is almost entirely handled by software.⁵

Toothsmith

Brooks knows that just because you have tools, it doesn't mean that they will always work or that the team will know how to work with them. As a matter of necessity, Brooks recommends the team include a toolsmith.

 

The need for a toolsmith is as great as ever. Ironically, this position is seldom funded and usually lands as an extra duty for one of the better programmers. As a practical matter, this means one of you best team members is making a small contribution to the actual product.

Tester

Brooks know that it's not going to be right just because the programmer said so. He recommends that a team include a tester. Nowadays we'd call this an independent tester. The role is now considered de rigueur.

Language lawyer

From the earliest days, high-level programming languages have been as vague and suggestive as a sacred text. If a team is to work against a common understanding, official interpreters are necessary. Brooks calls them language lawyers.

 

The term is now derisive. Nobody likes being told what to think, but most everyone recognizes commonality is better than anarchy.

Over the years the Surgical Team has been the target of pejorative commentary. However, it is still considered a viable team organization—no doubt because no suggestion by Brooks is to be taken lightly. But, the surgical team is now archaic, except for one thing: the existence of a chief programmer. In my experience, most of the better functioning teams have their most talented engineer working as chief programmer. NASA is a notable exception. Believe it or not, I was prohibited from naming a chief programmer because such a role did not appear in the institutional rules. Perhaps this is typical of a large bureaucracy.

Brooks does not provide all the guidance that's needed to staff the Surgical Team. He has failed to account for personal proclivities and career ambitions. This is especially important for a NASA software manager because the Agency is not your typical workplace. For despite its recent lackluster record, NASA remains the object of adoration for talented space romantics who imagine their own greatness and are eager to make a mark in the annals of space history. In particular, a manager must be wary that, by the modest exercise of authority, he might convert a team member, one destined rise to levels of influence and power, into an adversary. What's a manager needs is a scale that helps predict if a team member is destined for bureaucratic glory.

I've never been one to pass up the chance to remedy this sort of omission. After weeks of undisciplined research, I found inspiration in Jaroslav Hasek's classic study of the Austrian military⁶ and pulled together a new qualitative measure: Team Archetypes Scaled for Potential Glory (TASPG). It appears here for the first time.

TASPG seeks to predict how individual Surgical Team members will fare. The scale establishes a set of archetypes and the predicts likely ascension of each. (see Figure 1 below.)

The Archetypes

Straight-shooter

The straight-shooter is tone deaf or indifferent to the impact that actions have of the keepers of the treasury. Blessed with a clear and constant vision of what could and should be, the straight shooter lacks the ability to see that in reality the organization cares little for the end result. While there is little risk that the straight shooter can hit a political target, there is a genuine risk of ricochet which adds a creative aspect to management since a fertile imagination is needed to keep the monthly reports sounding worry-free.

Techno-purist

The techno-purist lives in isolation, always purported to be close, but never-ever reaching, a holy grail. She rhapsodizes on the object of her quest in an incomprehensible language. And, despite never seeing the work used in actual practise, the techno-purist has an undaunted, irrepressible, laser-like determination. She is convinced that funding is a birthright and the hereditary responsibility of management. While her babbling⁷ will never be understood by those who pose a threat in upper management, this fundamental bond of dependency ensures neither the techno-purist or the manager will ever be lonely.

Pollyanna

The Pollyanna has suffered many setback, but has confidence that this time things are different. At core he is an irrepressible and persistent optimist who eagerly brightens the day with hope despite all evidence to the contrary. This enviable trust in good things stems from a perennial inability to derive the future from the past. And, "since those without hope are wretched,"⁸ he makes an important contribution. There is little risk from the Pollyanna because, to paraphrase Prospero, hope is not the stuff that funding is made on.

Sycophant

The Sycophant is master of knowing agreement. He knows how to agree in just the right measure. As a patron's fervent protector, he knows with whom he should disagree and when. In ancient Rome, a triumphant general rode in a four-horse chariot past cheering hordes while a slave who whispered, "momento mori".⁹ Today's bureaucratic proconsul is more likely bring the sycophant along to handle the messy business of quarreling with a naysayers. However, like a fickle house cat, he is warm and affectionate, so long as there's tasty fare. But if a neighbor has better table scraps, danger lurks for any creature that resembles a rat or a bug. Be wary of the Sycophant.

Politician

The politician shifts adroitly with the winds of influence and fashion. Look behind your local Grand Poohbah and you will find the politician in his wake. He travels light; unburdened by principle or unneeded loyalties. And he's agile, ready jump Poobahs as the occasion calls. So, be on the lookout, the politician may soon jump into the express lane and pass you on the road to glory.

Foot Dragger

The Foot Dragger is the embodiment of mature engineering judgment. Possessed of a domineering judgement, she will climbed to the rank of senior technical lead as a reward for holding back progress. She can often be recognized by the rendering of a considered technical judgment with the words, "I don't understand." So, if you are stymied and your budget and schedule or evaporating, there is likely a Foot Dragger in the lead.

Perfectionist

The Perfectionist knows the dreaded consequence of compromise. He stands alone as the standard bearer of quality and the last bastion against the tide of disaster. While the perfectionist is unable to bring a task to conclusion, he is able to maintain technical ascendancy by subduing dissenters with disapproval. But you need not worry about the Perfectionist, the tide of events will surge past him.

Awfulizer

In the Awfulizer's assessment, failure lies at every turn. The broken interface, the overlooked requirement, the architectural mismatch, the woeful ignorance of managers all foretell of impending budget or schedule debacles. Success is always a miracle. The Awfulizer poses no direct concern for, like the beeping horns of Manhattan, the warnings are just part of the background. However, pay attention, for a warning may arm a hostile team with budget stealing rhetoric.

Figure 1: Team Archetype scaled for potential greatness

Note that the archetypes are not orthogonal. For example, a single team member, like the chief programmer, may be a combination of the Foot Dragger and Politician archetypes. The NASA data confirms this particular prediction. More sophisticated results that combine weighted assessments are pending. For example, a team member, like the co-pilot, may best be characterized as part Sycophant, part Politician and part Pollyanna with relative weights assigned to each.

Regrettably the TASPG project is unfunded; the results may be slow to reach publication. In the meantime, perhaps this preliminary result will serve as a guide for the harried manager who's trying to assemble just the right team.

---

^1. Hasek, J., "Good Soldier Svejk". Penguin Modern Classics. 1983. p 31.
^2. Mills, H., "Chief programmer teams, principles, and procedures,"IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
^3. I'm not certain if the term "surgical team" was from Mills papers or Brooks' description of Mills suggestion. If the former, there's a nice symmetry with Mills use of "Clean Room" for this development methodology. After all, you certainly want you surgical team to work in a clean room.
^4. Brooks was writing in the era before commercial products for configuration management and document generation were widely available. This is an extrapolation that may not reflect his intent.
^5. For projects of a couple of hundred people, there will often be a project librarian who manages an electronic libraries for documents. The programming artifacts are typically multi-tiered, but in the development phase a build manager usually is responsible for the source code repository.
^6. Hasek, J., "Good Soldier Svejk". Penguin Modern Classics. 1983.
^7. The word 'barbarian' was coined by the ancient greeks to describe people who spoke by making the babbling' sounds of a foreign language.
^8. Paraphrase from William Hazlitt, English critic (1778-1830)
^9. "...remember that you will die..." )

Small is beautiful, but not applicable

From Chapter 3: The Surgical Team

Excerpt
...one continually hears young programming managers assert that they favor a small, sharp team of first-class people, rather than a project with hundreds of programmers... But this naïve statement of the alternatives avoids the hard problem...the small, sharp team concept...is too slow for really big systems.(p. 30-31.)

From Small is Beautiful¹

Excerpt
One of the most fateful errors of our age is the belief that "the problem of production" has been solved. — Opening sentence of "Problem of Production (Chapter 1)

In chapter 3, The Surgical Team, Brooks takes on the topic of how to organization and manage a very large team. It's a hard problem. A very hard problem.

Why bother? Why not simply deploy a small team composed of the best people? Brooks cites a study from the 60's where highly skilled programmers were found to be 10X more productive that average programmers. More recent estimates put that ratio at around 4X.² In either case, the numbers are compelling. As if that wasn't reason enough, there's Books' Law : as the team gets larger, the number of communication paths grow. And, of course, the added complications that stem from decomposing the system into parts that can be developed on parallel paths. (See Humpty-Dumpty Effect).

What's not to like? Why would anyone, ever, approach a project with a large team?

IBM System/360

 Brooks offers this compelling analysis based his experience on the IBM System/360 Project³.  Brooks estimates that, if you included all members of the development organization⁴, the System/360 took about 5,000 man years to build. He recalls that the original project plans called for only 200 people. However, at one point, there was over 1,000 people working on the project. He then surmises that "if "men and months traded evenly" the project would have taken 25 years. In other words the System/360 wouldn't have delivered until the late 80's when PCs and workstations dominated the marketplace; in which case, the System/360 would have been embarrassingly obsolete and a certain business disaster.   

What if the system was built by a small, highly talented team? Would that have been preferable?

Brooks offers the following analysis. He assumes a team of 10 since that is the largest practical size for a small team.⁵ For the sake of discussion, he assumes the staff on the small team is 7-times more productive than people who actually did the System/360 job. And, in order to make the most favorable case for a small team, he throws in a 7X bonus because there are fewer communication channels. In other words, he's going to assert that the small team can produce products nearly 50-times as fast as a large team. The result: the small team gets the job done in just 10 years. However, that's over twice as long as the actual project. In other words, the System/360 would have come to market just about the time DEC introduced the VAX which was a significant advance over the IBM 360. Once again the result would have been a business disaster for IBM.

Note that Brooks' analysis does not account for the new technologies that came to market during this period.⁶ If you bear those in mind it's likely the System/360 project would have been stuck in a cycle of endless catch-up and never been completed. In other words, a large team was necessary for the System/360 to be a viable product.

---

The development of a space system also requires a large team. Development of the integrated flight/ground systems is a large-scale undertaking requiring coordination between many disciplines. For the sake of discussion, just consider the software; it will provide some insight into the scale of the undertaking.

Here's a partial list of software teams who typically participate in the engineering of a mission.

Collage of NASA Teams

• A flight software team that typically includes managers, software-system engineers, programmers, and testers.
• A flight hardware team that uses programming languages (i.e. software) to build the computer components used on spacecraft⁷. The hardware team typically includes managers and electrical engineers.
• Several teams of engineering discipline analysts. The analysts participate in both the development and operation of the spacecraft. These displines include attitude control, power, navigation, and mission planning to name a few. Some of the discipline teams are very large (e.g. navigation), some are small (e.g. power).
• Several teams of scientists who build and operate the spacecraft instruments.
• A team responsible for spacecraft command tools. This team usually includes managers, software-system engineers, programmers, and testers.
• A team responsible for the ground system integration and infrastructure. This team usually includes managers, software-system engineers, programmers, and testers.
• The teams responsible for the space communications infrastructure. There are many aspects to the communication system and, in its own right, is the size of a mission
• A team responsible for payload and booster integration and the infrastructure needed to support it. There are many aspects to the communication system and, in its own right, is the size of a mission.
• A team responsible for turning raw data in to engineering and science data products. (e.g. producing the pictures taken by the rovers.) This team usually includes managers, software-system engineers, programmers, and testers.
• The public relations teams needed to set up and maintain web sites and other social media.
• Institutional IT infrastructure teams who are responsible for setting up all the computers and networking

---

In Chapter 3, Brooks describes an approach for organizing a large teams that would make them practical. In a nutshell, he defines a hierarchical organization that reduces the communication paths. This will be the subject of subsequent postings. But, in my experience, this hierarchical arrangement does not work. It inevitably produces a bottle neck around the leadership. It often proves to a recipe for indecision since the line of responsibility is unambiguous. What's more, the guys in the trenches are often a LOT smarter than the appointed technical leads who are, too often, selected for political skills rather than technical talent.

You need a large team to build and fly a space system. We haven't made much progress since Brooks wrestled with the System/360. Large teams offer substantial challenges, many of which have no known solution and would be a suitable research topic. There is no authoritative list of capabilities that are needed to manage a large team, but here's few suggestions:

• A highly-expressive means for describing system design and system function that permits consistent interpretation at all levels of abstraction and realization. This would dramatically decrease the number of high-bandwidth communication paths.
• A robust and expressive interface description method for specifying requirements, design, signatures, protocols and the functional semantics behind the interface. This would provide a basis for a robust emulation strategy, system-wide continuous integration, and the development of early and stable test routines.
• Planning tools for efficiently developing and modifying detailed deliveries. This will provide overall visibility of how changes in one team may propagate across the development effort. ⁸
• Configuration management tools that with 'smart' support for parallel development of multiple code branches (or streams)—i.e. no hand merging. This will enable a means to project-wide continuous integration without drawing programmers away from new code development.
• Automatic and non-invasive metric collection tools that provide visibility in to progress and quality. This will substantially decrease the effort required to support management oversight.
• A novel risk assessment methodology based on an automatic and achievable testing protocol. This will provide an substantial method for understanding of the state of product without relying on the unrealistic hope of comprehensive testing

You might note that none of these suggested capabilities add functionality to the system, only to the system that's needed to build the system.

While there is a plethora of tools (e.g. IM, issue trackers, stream-based CM systems, etc.) that help facilitate current practice. As far as I know, no one has the tools or techniques needed to address the problems confronting a large development organization when it builds a large and complex system like a space system.

Some day engineering practice may evolve so that building things of inordinate complexity will be within the grasp of a small team. Meanwhile small is not practical.

---

^1. Schumacher, E.F., "Small is beautiful: economics as if people mattered". Harper & Row, 1973.
^2. In Barry Boehm's essential cost-estimation text, "Software Cost Estimation with COCOMO II," he estimates that a highly skilled team, on an "largely unprecendented project, like building a new spacecraft is slightly over 4X more productive. See Boehm, B., et al. "Software Cost Estimation with COCOMO II." Prentice Hall. 2000. p.32.
^3. Brooks was manager of the System/360 project from 1961- 1965.
^4. Books includes programmers, writers, machine operators, clerks, secretaries, managers, support groups among those he counts as part of the development organization.
^5. Brooks doesn't make it clear who is included in the 10. I assume he means 10 programmers. That would probably come to a full team of 20 as follows: 1 manager, 1 administrator, 2 Systems Engineer, 10 programmers and 6 I&T (i.e. Testers). By contemporary standards, that is NOT a small team. Here's how I would define a typical small team: 1 manager, .5 administrator, 1.5 Systems Engineer, 5 programmers and 4 I&T. In round numbers, I'd expect the annual budget (in a contemporary aerospace company) for the former to be around $6-7M. I'd expect that latter to be $3-4M.
^6. A few of the improvements include important advances in instruction sets, memory access, graphics, networks, operating systems, and programming languages.
^7. Hardware is "written" using verilog or VHDL to build devices like FPGAs . Hardware teams typically do not use conventional software engineering techniques that are considered best practice. By and large most hardware managers do not think of software development as part of the hardware development process.
^8. The need for reliable delivery of specific functionality calls into question the value of using agile development techniques in a well managed software effort. Since, by definition, the results of an agile task is unpredictable.