Singularity: Dependability Really Does Matter

In a recent (well, today's in fact) Dr. Dobb's Report I took a quick look at Singularity, an interesting project coming out of Microsoft Research. I heard back from readers Ray Rathburn, Donald Bertke, and Brian Gladish, whose follow-ups where, to my mind, more interesting than my original overview. So what follows is my original note, followed by their response.

Here's what Ray Rathburn had to say:

Several years ago, probably 10-15, there was an article about how NASA developed software for various spacecraft-related projects. It was very interesting in that they used peer code reviews and a very involved process of testing and reviews at multiple stages of development. The end result was extremely reliable software with zero errors, but the article also pointed out that the cost per line of code, even then was 6+ figures. Zero error code is possible if you have enough money. To determine what to spend on testing and development, you have to ask the question "what is the cost if the software fails in use". There was a satellite launch (by a European consortium, I believe) that aborted. The rocket and satellite was destroyed costing 100's of millions. It aborted because two navigation software modules weren't tested together. Several seconds after launch when one module sent the other a position as long integer and the other expected a short integer, it didn't compute and so since it didn't know where it was at the safety fail safe set off the self destruct. Skimping on testing is not the best place to save money. The real question when determining how much to spend in development and testing is "what is the cost of failure?". (How much testing does the FDA require of medical devices?)

Donald Bertke added:

I just looked over you synopsis of the Singularity Research at Microsoft. I am glad that someone is finally looking at software as a dependable process. In my younger days, I was programming embedded systems as a contractor for the USAF and we had to make the software work first time, everytime, before they would let us even test the software in a real system. The current generation of programmers have no conception of how well and tight we wrote software in those days. It sounds like the Singularity research has hit upon what we considered the golden rule of embedded software:

If you follow these simple rules, your software will run quickly, reliably, and be easy to maintain. I hope the Singularity project takes off and gets people to write better software.

And then Brian Gladish said:

 In the 1960s a company named Burroughs (now Unisys after the purchase of Sperry) built systems  (the B5000/B5500) that, through hardware, precluded modification of code (this feature was called "re-entrancy") and ran user programs that were guaranteed not to touch memory outside their domains.  In the 1970s the B1700 implemented interpretively in small systems what large systems had implemented in hardware, effectively creating what MS calls a "managed" environment through software (vertical microprogramming in this case).  Burroughs large systems' operating system was written in extended ALGOL, while the small systems' O/S was written in SDL (Software Development Language), an internal, proprietary language.  It is unfortunate that these advances seem to have been lost and must be rediscovered after so many years of coding in unprotected, C-based environments.

Thanks Ray, Donald, and Brian. Anyone have anything to add?

.