"The Grip of Tar"

From Chapter 1:

Excerpt
Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. (page 4)

Brooks begins the Mythical Man-Month with a summary of the difficulties he encountered as manager of the IBM 360 project. He notes that most programming efforts have failed to meet planned schedules or budgets. He specifically calls out a few sources of trouble: intolerance to defects (software must be 'perfect'), the disconnect between responsibility and authority, the travails of testing and debugging, and the certainty of obsolescence. He also admonishes us to consider that developing a software "product" is an order of magnitude more expensive than just writing a program--an all too familiar experience for those of us who have had to maintain our own products. Brooks does soften this bleak message with a tribute to the joys of programming, but the main point is that, back in the 60's, software development was a tough business.

It's still a tough business. During the first decade of the 21st century, the NASA software development culture fits the tar-pit depiction. Brook's observations remain relevant, but the problems confronting NASA software developers are more diverse. In subsequent postings, I plan to reflect on what software developers encounter in the space biz and why.

To first order, the development challenges originate from the technical domain and the culture. The technical challenges stem from the diversity inherent in the system (flight/ground), the complexity of operating in a physical environment and the need to autonomously respond to faults. The cultural challenges stem from the engineering biases inherent in a dominant hardware culture, the dependence on government funding which is inherently political at all levels and the time-tested conservatism characteristic of large bureaucracies. Added together you might say that the budget, schedule and technical challenges are the result of risk-adverse decision making in response to highly constrained budgets by a management that prioritizes hardware concerns.

During my years at JPL, I was often dismayed by decisions that struck me perniciously wrong-headed. However, with the wisdom of hindsight that comes from retirement, those decisions (which still seem unfortunate) were fundamentally rational in the context of the NASA culture. To put it another way, the agency is staffed with dedicated, highly talented managers and engineers who would be acting against their own best interest if things were done differently.

Obviously NASA has enjoyed tremendous success in both manned and planetary exploration--tremendous credit belongs to those who have developed and operated those systems. But, so far, we've addressed the easy software-engineering challenges. The tough challenges, those that must be met if were are to build affordable, reliable space systems, remain. We've barely scratched the surface.