I must thank you for that link to the excellent article on the software design process used for the Space Shuttle. In the context of your thread title it reminds me that security isn't really special but should simply be another part of the software specification, a specification that is so well thought-through that one wouldn't need to put special attention on security in an attempt to make sure it worked. The focus on security (or any other feature) almost always fails to some degree, and it seems that it isn't security that is the problem, it is the whole software design process that is the problem.

The shuttle article discusses at length the differences between the software design culture and other more established professions, and this also reminds me of the ongoing debate in some circles about whether "software engineering" is really engineering, and whether it should be. (We have discussed this here before, here is a good example).

This leads me to your final point that this can be done. Frankly it is already done (but as you point out it needn't be carried to this extreme) in most other fields as illustrated by the number of things that don't fail every day (the old joke about what a Microsoft-built car would be like contains some perceptive and valuable comparisons). Why do we tolerate and even expect failure in software? I'd like to offer yet another plug for the Risks Digest as required and regular reading material for anyone designing anything - patterns of risk and error appear in all fields and much can be gained from the exercise of seeking parallels.

From the Fast Company article:

...Software is getting more and more common and more and more important, but it doesn't seem to be getting more and more reliable.

...admittedly they have a lot of advantages over the rest of the software world. They have a single product: one program that flies one spaceship. They understand their software intimately, and they get more familiar with it all the time. The group has one customer, a smart one. And money is not the critical constraint ... the group (is) among the nation's most expensive software organizations.

Now imagine if you will that the world's most popular OS had been built this way. For the vast majority of users, it would have saved countless hours of frustration and unproductive time, easily justifying a much higher per workstation price tag. Certainly there would be disadvantages (the first that comes to mind being the lack of flexibility), and it is difficult to see how this could have come about on such a scale, but to me it is an interesting scenario to consider.

--
I'd like to be able to assign to an luser