Trustworthy Computing

Note this is the first class discussion post in this weblog. All class discussion posts are specifically for my current students but past students and visitors are welcome to add their comments too.

Microsoft's next operating system, code named longhorn http://msdn.microsoft.com/longhorn/, touts as one of its new initiatives trustworthy computing. Recall that trustworthy software is stable, does not crash with minor flaws and will shut down in an orderly fashion with major flaws. What does this mean when dealing with an operating system and does it mean different things to different users of the system? I suspect that a consumer, a business person, an administrator and a developer have their own concept of what trustworthy computing is and what is an acceptable result when encountering a failure.

What is your view of acceptable results in the midst of failure for each class of user? What are unacceptable results?

Stressed Out

In Professor Bernstein's paper on fault tolerance he discusses a classical engineering technique that involves stressing a system until it breaks and then certifying it for considerably less than the breaking point. I was wondering to what extent this technique is used in software testing and certification. How many of you have done this in any system that you have produced either academically or in industry? I estimate that less than half of the systems I have been involved with have: (1) been stressed and (2) certified for much less than the stress point. This is despite the fact that in most instances of systems that we stress tested, it avoided a major fiasco.

So the open question is how many of you stress test each system and, if so, do you certify the system, or make sure it operates within, parameters much lower than the stress point?

On Documentation

Deciding how to structure documentation at the command level has been really straightforward thanks to such things as unix man pages, javadoc (although I hate automated documentation schemes) and the web. However it becomes a bit more difficult when you have to document a system. Most system documentation provides a roadmap of the commands, command pages and data dictionary. Developer documentation usually describes the routines/classes with appropriate args but not much algorithmic description or system description.

What do you consider an acceptable framework for system documentation. Can you cite any examples that are accessible on the web?

Comments please! Thanks!

Open Source

Yesterday on slashdot (http://slashdot.org) A review of Eric Raymond's new book, "The Art of Unix Programming" was posted. As some of you may remember from my CS540 class (Introduction to Quantitative Software Engineering) Eric has chronicled the Open Source movement through such gems as, "The Cathedral and the Bazaar, " "Homesteading the Noosphere," and "The Magic Caldron." The best part is that, in true open source fashion, he is offering it on the web for free! Browse the book at http://catb.org/~esr/writings/taoup/. If you enjoy it and have the cash, buy it. We need to keep Eric going.

Also the Halloween papers, that chronicle Microsoft's response to Open Source, continut to be issued. The count is up to Halloween IX! Later.

Logbook Entries?

Would it be worthwhile to provide a weekly logbook entry in this blog? I would post either one of my own or (with permission and attribution) a logbook entry from a present or former student. If former students would like to post an entry please email me the entry and I will do the posting. Thanks!

New Testing Book

I am currently reading a new testing book, How to Break Software: A practical guide to testing, by James Whittaker, ISBN:0-201-79619-8, Addison-Wesley, 2003. This is the book I mentioned in the CS540 lecture class. It approaches testing as a series of attacks, similar in approach to how secure systems are challenged. It is a good addition to any testing program. He stresses ingenuity and flexibility in testing. Recommended!

On Blogs and Information Overhead

If I would pan a camera around my home study you would see, bookcase crammed with books and the floor stacked with heaps of books and notes. Some of these heaps relate to the two courses I teach and the one I am proposing, others relate to alife and AI and others relate to my work at AT&T Labs. My browser bookmarks could be divided in a similar fashion as could my NetNewsWire Blog index. (This ignores my non-professional reading list including Pattern Recognition - Gibson and Canticle for Leibowitz - Dennett.) Similar heaps can be found in my office at AT&T Labs. And then there are the enumerable unread or partially read email messages and my excursions into netnews.

The point I am making in this enumeration of my local mind clutter is that information overload not only still exists but also that additional venues (blogs, email, web) have multiplied it! So, given that, why I am I contributing to this overload by adding my own blog.

My defense is that blogs, especially topical ones like this, are the equivalent of textual expert systems and are an attempt to reduce the information overload rather than contribute to it. They provide for self selected subgroups that compile and synthesize information. And because they are mostly pure text, the message and the effort is not lost in the medium unlike many web sites which become increasingly involved in their media and design excursions.

Hopefully this blog will fulfill that purpose especially for myself and past and present students.

First Light

This blog is especially for my past and present students at Stevens Institute of Technology to continue our explorations of the software universe. Past and present students of my CS 540 (Software Engineering) and CS 565 (Software Architecture and Design) courses are welcome to email submissions to me. I will post them as soon as I can and of course will credit you with the submission. Of course you can comment directly on any of the submissions by just hitting comment.