Modest Expectations

From Chapter 2: The Mythical Man-Month

Excerpt
This then is the demythologizing of the man-month. The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. One cannot, however, get workable schedules using more men and fewer months. More software projects have gone awry for lack of calendar time than for all other causes combined. (p. 26.)

With those words, Brooks wraps up the pseudonymous chapter of his classic text. If there is any law for managing a software project, it's Brooks' Law: Adding manpower to a late software project makes it later. The mechanism is well understood and the basic concept broadly accepted—for decades. And yet, in program after program and project after project, the law is re-proven as if it was a traditional student experiment in a first year college lab.

I'm reminded of Santayana's often cited admonition:

Progress, far from consisting in change, depends on retentiveness...when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. "¹

If you think about it, not all history is repeated. We're particular good at repeating the mistakes. Why not the successes? How does that happen? Specifically, how does it happen in NASA?

---

The the other night, I was having dinner with my good friend 'TJ'. He was reminding me just how cool it is to work for NASA. People are living in space. A rover is driving around on Mars. We are getting images of exoplanets. His enthusiasm was genuine and infectious.

International Space Station (May 2011)

He's right of course. These things are cool, but they seemed tepid compared to what NASA did during the Apollo era. Is driving a Martian rover 100 yards comparable to walking on the moon? Does the first space walk compare vaporizing a Martian rock? Does the return of the Lunar Excursion Module (LEM)and re-docking of the LEM after a moon walk compare to the maiden docking of Dragon Module?

Back then NASA engineering was breaking new ground. No longer. We build spacecraft the same way we did 30 years ago. The new systems are still fragile and expensive to operate. And what about the ongoing existential crisis regarding the purpose and value of the spacestation. Does it make sense to spend more than $3B per year to keep astronauts on board to see if vegetables will grown in space? Is this headed anywhere? What's happened to the agency vision?

Later that week, I met my good friend, 'KN' for lunch. We had worked together on many tasks and shared disappointments from working on the wrong side of the political equation. That day he was surprisingly optimistic. He seemed to think that, at long last, a meaningful change was at hand. His project has committed to use model-based engineering techniques.

Over the years we'd seen similar decisions come and go. 'KN' is an old pro, no Pollyanna. Perhaps this time it would be different. Perhaps this was no mere lip service. Perhaps when the coding starts, these new techniques will actually be used. This was a glimmer of hope. But, as I thought back on the effort needed to obtain management consent for this small innovation, I wondered why significant engineering advancements for a NASA were merely routine decisions elsewhere.

What was imagined in the 1970s

Back in the 70's, expectations were different; great achievements were expected. NASA was confident and flush with success. Routine and cost effective access to space was surely in reach. NASA built the shuttle. In order to travel past the Moon and beyond, we needed a jumping off place. NASA started work on a space station. These were bold objectives. Humans were about to push into the frontiers of space and NASA was in the lead.

That's when the setbacks started. The shuttle was delivered 2 years late. There was a tragic accident. The space station project became a muddle and nearly abandoned. NASA had overreached. Doubt crept into the culture. By the late '80s the Agency's growing conservatism slowed the pace of innovation. The engineering values shifted to predictability, risk reduction, and cost savings. Along the way, something changed—expectations were no longer great.

In the last decade the government tried to reenergize NASA with the Constellation Program (Cx). The goal of Cx was to return to the Moon and enable travel to Mars. From the outset, the program was cursed by an unrealistic funding profile, a fanciful schedule, and the rigid bureaucracy that sprouted since the glory years. The result: Cx floundered for 5 years before being mercifully cancelled. However, despite these crippling constraints, Cx did leave a legacy in the Orion Multipupose Crew Vehicle , the Space Launch System and the Commercial Orbital Transportation Services. These programs produced sensible vehicles that are basically Apollo-era recreations with modest improvements. Modest; sensible; but not especially inspiring.

The new Orion Multi-Purpose Crew Vehicle

Aside from occasionally bouncing or dangling rovers to the surface of Mars, the Agency's technical feats do little to animate the public's imagination. Now-a-days, it is the high-tech rainmakers, and not NASA, that feed the public's space appetite. Commercial space tourism companies tout the glories of a sub-orbital dip into space. Space cults recruit romantics who are clamoring to board a one-way trip to Mars. There are raft of grandiose projects, like space elevators and asteroid trappers, whose proponents proclaim their practicality with only the slightest consideration of the potential for complication.

---

It is this drift away from a culture of inspired, innovative engineering that is telling. Both 'TJ' and 'KN' are realists. They are professional. They are not complacent. They have internalized what's possible in the engineering culture of NASA.

Internalization of culture is a key to NASA's repetition of merely modest and just sensible engineering achievements. I saw a transformation in nearly every new hire. Most come on-board agonizingly eager, talented, and bubbling with ideas. They know little of the realities of engineering in the space business. In a few years most absorb the conventional wisdoms that engineering judgment rests on current practice and innovation lies on the borders of the status quo. They learn that engineering between the lines is the mark of professionalism. The result is an inward-looking, myopic culture busy with immediate concerns and reluctant to tamper engineering custom—even when that custom is to add programmers to address schedule problems late in the project.

---

"Spider" concept for spaces station
 built from Shuttle hardware

There will be some fundamental assumptions which adherents of all the variant systems within the epoch unconsciously presuppose. Such assumptions appear so obvious that people do not know what the are assuming because no other way of putting things has ever occurred to them.²—Whitehead

We are rewarded for internalizing the conventional assumptions and practicing the conventional methods. The problems occur when the circumstances,that gave rise to a convention,are no longer relevant. Knowing history is not enough to avoid the errors of the past.

I'd like to think I'm an optimist—perhaps one whose hope has been attenuated by disappointment. I don't believe we must repeat history or be mastered by convention. We can question fundamental assumptions. We can develop new approaches that will enable us to build the systems that were imagined in the 70's. If only a few remain tough minded and work to think past the assumed truths, 40 years from now the next generation will look back at the Mythical Man-Month and say: "It's a good thing we don't do THAT anymore."

With that, I'll move on to the next chapter: "Surgical Team."

---

^1. Santayana, G., "Reason in Common Sense," The Life of Reason. Dover Publications Inc. 1980. Vol 1. Chapter 12, page 291.
^2. A.N. Whitehead. Science and the Modern World. Free Press Paperpack. 1925. p.48.

Seven at a single blow

I still have lunches with my old chums from my days at JPL. On several occasions I've heard, "OK, we know there's problems. But what would you do to make things better?"

The question has been nagging at me. It's one thing to sit on the sidelines an take pot shots, it's quite another to take specific actions. I've been thinking...

How would you even approach the task of changing a very large, inflexible government bureaucracy to refocus its energies from a stovepiped, hardware-centric mindset to a unified software/systems-centric approach? New Leadership? A massive reorganization? A huge infusion of cash? Nah. It's all been tried with no more impact than a sand flea's assault on an elephant. Why?

Large bureaucracies are a civilization's great stabilizing force. The longest-lived civilizations, Egyptian, Chinese, Roman¹, all developed powerful bureaucratic institutions. They arise naturally around the seat of power and grow into competitive dominions that will perish if not defended. Since change threatens the division of authority, the power of its management, the livelihood of its minions, and even the bureaucracy's very existence, protective barriers emerge like great jetties against the tide of change. So while bureaucracies stabilize, they also paralyze. It is their nature. Any attempt to change the bureaucracy is a non starter.

What's needed is a strategy that would produce a change by using a bureaucracy's existing machinery.

There's no explaining why, but the story of the Valiant Little Tailor sprang to mind. If you don't remember, the little tailor is an insignificant person who was about to enjoy a lunch of bread and jam when, to his dismay, a swarm of flies lands on his jam. In a moment of pique, he grabs a piece of cloth and swats the flies. The result: 7 flies meet their maker. The little tailor takes great pride in this feat. He wants the world to know, so, he embroiders a sash with the words "seven at one blow" and sets off to make his fortune and eventually rule a kingdom. ³

The story got me thinking. What small feat might trigger the dominos of change, get the Agency out of the current rut and put the space program on a path to develop a new space system that would excite public interest and reestablish the nation's leadership in space technologies? What would disrupt the division of bureaucratic authority and trigger the survival reflex. What if there was a challenge comparable to that faced by the engineers in the Apollo program. What if the Agency decided it was going to build a new kind of system for a flagship mission with requirements that simply could not be produced by current practice? What if there were 7 requirements that would set in motion a fundamentally constructive change?!

"...almost all really new ideas have a certain aspect of
foolishness when they are first produced."⁴ A.N. Whitehead

Inspired by this challenge, I put in a good bit of careful procrastination, day dreaming, weed pulling and cloud watching. Failing any real insight or inspiration I finally sat down and dashed off 7 requirements that, if mandated, might force the development of a new type of space system--one that would set a new standard for how NASA conceived and developed its spacecraft.
Note: These are non-functional requirements; i.e. they describe how the system would be built or how it would perform. (By contrast, functional requirements describe what functions the system must perform.)

The 7 Requirements:

1. The proposed mission budget shall account for the mission's complete cost-of-ownership from formulation through operations where operations includes an extended mission phase that is three times the duration of the primary mission.

Rationale: Mission proposals typically reflect a minimum operations budget as an artificial means of reducing the cost to fit under a cap. The practice is always successful because, once the systems is flying, it becomes a valuable asset with vested interests that no seasoned bureaucratic would abandon. Consequently, extended missions are almost always funded. However, since the actual cost of lifetime operations is never reckoned in the original proposal, there is no justification for innovations that would make a spacecraft more reliable or cheaper to operate. If the full cost of ownership was taken into account, that balance would shift and it would be cost-effective to build a better spacecraft.

2. The flight and ground systems shall be unified into a architecture with a common design philosophy and shared information architecture

Rationale: A common flight/ground architecture would undo the existing stovepiped architecture that's been frozen in place by the vested institutional factions that comprise the bureaucracy. The shared information architecture would narrow the gap between systems and software engineering and eliminate the class of errors that lead to the loss of the Mars Climate Orbiter and Mars Polar Lander.⁵

3. The project shall be limited to 36 months.

Rationale: The products created in initial phase of the project are usually cast off when the 'real work' begins. A short schedule will force the team to act decisively from the onset. And, because the schedule is short, institutions will be motivated to invest new approaches before the mission development begins.

4. (a)The technical lead shall include a 'decide-by' date for every technical decision requiring management approval. (b)Managers shall respond to these decision requests with an unambiguous decision before the 'decide-by date' or be replaced.

Rationale: In a large bureaucracy, decisions are inherently risky. Managers tends to delay decisions until the options are no longer relevant or until a committee consensus has been reached. This requirement would encourage managers to assume individual responsibility. It would also provide the development teams with timely approvals.

5. Each functional requirement shall include at least one test scenario with success criteria.

Rationale: Requirements expressed as natural language shall statements are typically vague. Even modeled requirements may leave plenty of room for interpretation. By comparison, a test scenario clarifies the intent of a requirement by providing a concrete and specific instance of what the function should do. Clearer requirements help programmers build the right product and avoid costly defects from miscommunication.

6. The staff needed to complete all mission operations activities shall be limited to 5 engineers.

Rationale: Operations for a flagship mission like MSL typically require dozens of engineers and an annual budget of double-digit or triple-digit megabucks. A team this size is needed to manage trajectory change maneuvers, in situ maneuvers, science planning and recovery from system faults. However, these costs could be dramatically reduced if the system was conceived and built as a unified flight-ground system designed for autonomous flight. Without a requirement to fly with a very small team, the Agency business model coupled with the need to feed the current engineering cadre will prevent the development of an autonomous system.

7. Board members for software reviews shall be prepared to provide the development team with a detailed technical accounts of any reported findings.

Rationale: In the current process-centric, Agency culture, review boards are inclined to focus on checklists of documents without close examination of the engineering described in those documents. Board members seldom have the time or skills necessary to examine key technical design choices. If board members were knew they might have to discuss technical details, the board would prefer in-depth, engineering-focused presentations to a rehearsal of process compliance.

No doubt someone with superior engineering judgment would produce a better list. However, even this paltry list could serve to shake things up. But only if someone with authority was foolish enough to confront the giants and unicorns and insist on building a system with 7 disruptive requirements. It's an unlikely prospect— bureaucratic managers are selected because they lack those very qualities. However, if by some oversight or error, the highest levels of the Agency approved a disruptive project, I'd walk away from the joys of retirement and do my darndest to secure a spot on that team.

---

^1. The Egyptian empire lasted roughly 5,000 years. The Chinese empire roughly 3,500 years. The combined Roman State (Republic + Empire) lasted about 1,100 years.
^2. Interestingly both Roman and Chinese bureaucracies were staffed by eunuchs.
^3. Fortunate he was! The little tailor went on to outwit 3 giants, a wild boar and a unicorn on the way to win a princess and a kingdom. In this story, hubris pays off.
^4. Whitehead, A.N., Science an the Modern World. Free Press Paperback. 1925. p.47.
^5. I know of one architectural approach that meets this requirement: The Mission Data System (MDS). MDS was developed in the last decade, but never used. Perhaps there are other approaches.