Novel System Engineering

I just finished William Gibson's novel, Pattern Recognition (Putnam, ISBN = 0399149864). It was fantastic and highly recommended. Gibson not only tells a great story but he also writes really well and he is extraordinarily creative. In fact I believe his creativity regarding visions of the near future provide the systems engineering of human computer interaction for the next generation of computer scientists.

Another novelist who falls in this category is Vernor Vinge, who is a computer scientist. If you have any spare time, try reading his short story "True Names," a classic.

So do you believe that novelists of this caliber can become our systems engineers for shaping the future of human computer interaction? Are there other novelists that fall in this category? ( I know of a few more but would like to hear from you first.)

A key to this discussion is understanding that what you do as professionals is shaping the future and there is fun and excitment to it. There also is a heavy dose of responsibility. Novelists such as Gibson make both clear in their works. Later!

On Heisenbugs

A Heisenbug is a software error whose presence is affected by the act of producing it. It is a bug that occurs in fielded software but when you try to simulate it in the lab it is difficult to reproduce. Mitul Patel, a student in my online course had this experience recently. They thought they remedied the problem but they had a difficult time convincing their management and customers that it was fixed since it was difficult to reproduce.

Heiesnbugs are not that uncommon. Do you have any suggestions on how to deal with them or any personal experiences with Heisenbugs? It would be especially helpful if you have some strategy to test it and convince others that the bug has been swatted. Thanks for your input, later!

(Professor Bernstein's paper, “Software fault tolerance forestalls crashes: To err is human; toforgive is fault tolerant.” discusses Heisenbugs and can be found at my web site http://homepage.mac.com/vesonder in the CS540 notes.)

Programs as Literature

Given our recent discussions on Open Source, I just wanted to bring to your attention a great book on reading code, "Code Reading: The Open Source Perspective" by Diomidis Spinelis, Addison-Wesley, 2003, ISBN: 0-201-79940-5. Although I am only into the 2nd chapter, it is an impressive effort and is highly recommended. The key concept is to learn by reading code and he shows us how to do it systematically using numerous examples from Open Source archives. He advocates that reading great code will make you a better developer and I agree. I read a lot of code in the late 70's at Bell Labs tutored by folks like John Mashey and Mike Bianchi who knew Unix backwards and forwards and it served me well.

So the discussion topic is simple (and not only limited to current students), do you read code? How regularly do you read it? Do you do it systematically? Is your code reading above and beyond, "I need to understand this code fragment to make my code work?" Do you read some code purely for education and fun and, if so, in what language?

If you haven't read code for fun, try it! If you do try it, we all would appreciate relating your impressions of the experience on the blog. Later!

Rules Rule

In the Intro to Quantitative Software Engineering (CS540) class this week we discussed OO Analysis and Design. During the lecture I went into my usual monologue that OO is too predominant in current CS. I went on to say that there are other really useful and used programming methodologies. Of course this is not a great revelation! However one methodology that has been virtually ignored in modern development practice is rule-based programming and data driven methodology. (So much so that I think that my next blog will be devoted entirely to that.)

So the discussion question is: How aware are you of the rule based/data driven methodology? Has anyone in formal coursework mentioned it? (Besides me) Have you or do you use it in your own development projects? Would you use it if given the chance to learn it? Do you think a Blog and web site devoted to it would be helpful to get you started?

As always thanks for your comments!

On error handling

In my classes I emphasize that it is important to provide adequate error handling in your code, but I also admit it is a real pain to do and one of my least favorite coding tasks.

Greg Horvath, CS565-'03, sent me a url to an article by Andrei Alexandrescu and Petru Marginean on Enforcements in the C/C++ Users Journal, http://www.cuj.com/documents/s=8250/cujcexp2106alexandr/. Andrei also is author of Modern C++ Design: Generic Programming and Design Patterns Applied, a very popular C++ patterns book, that Greg recommended in class. Getting back to enforcements, they are on the fly condition verifiers. The article is really well done, providing code and examples of using enforcements. Their short discussion of architectural patterns, design patterns and idioms alone is worth visiting the url. It is a companion to a previous article on assertions which is on my queue to read between terms.

I'd like to again thank Greg for the recommendation and encourage all of you to suggest articles and books to read that can be shared on the blog.

I also would like to thank folks for commenting on current blog entries, keep the dialog going! Later.

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?