The second volume of Development of the Space Shuttle arrived today. The first volume Space Shuttle Decision describes not only the shuttle but the early concepts of a reusable vehicle. While these books are interesting reading (at least to me) they convey something more important.
Our modern world of software development is very risk adverse compared to the development of manned space flight.
At the same time, the risks taken to design, develop and operate a spacecraft are mitigated with intensely deep technical, programmatic, and managerial risk management processes
I was sitting in planning meeting this week, when someone mentioned "what are we going to do about the Design Certification Review" for our master program plan? Not being fully aware of all the details I asked - "what is that?" The answer is that the DSR is a full top to bottom assessment of every design decision and resulting manufacturing and test outcome for the launch vehicle prior to the Flight Readiness Review (FRR). At the FRR the question is - are we ready to going flying?
As the resident IT guy on the program management staff - most everyone else is a System Engineer or Propulsion Engineer by training and experience - I thought about how software in the commerical world is built. It's built in pretty sloppy ways, with poor discipline, lots of hand waving, papering over problems and mostly trying to convince management that things will be alright if you just let the programmers do their job.
The question is - is there anything we can learn from the spacecraft business that is applicable to software development? And of course there is...
- Think like a systems engineer - ask big picture questions about mission and vision. About the "concept of operations." About the Integrated Product Team. About technical and programmatic performance. About technical and programmatic risk management.
- Focus almost exclusively in the interfaces between components before getting into the details of "how" things should work. Its at the interface boundaries where the design is "lost." Nouns, verbs and the idioms of their use is the basis of understanding how things are put together.
- Make "mission assurance" the over arching goal of any activity. This means "test first design." In the spacecraft business no design can survive the review process without first answering the question - how are we going to test this thing?
- Speak in terms of collaboration and interaction. Use heuristic and participative interactions with the team members rather than normative and rational processes.
The Core Concept of Developing Software as a Systems Engineer
Complex systems will develop and evolve within an overall architecture much more rapidly if there are stable intermediate forms, than if there are not. – The Art of Systems Architecting, Second Edition, Mark Maier and Eberhardt Rechtin, CRC Press.2000
