About Feasibility

Attached is a logbook entry from Sushil Vachhani, a student in my Intro to Quantitative Software Engineering class. He writes about practical experience with feasibility studies. It is a great post.

Comments are encouraged.

I was once considering writing a program that would convert C++ code to Java code. I was deciding on several preliminary issues as to how would I go about it and in what language would the source code be written, C++ or Java? I chose C++ because I was more comfortable with its file handling features at that

time.

I knew that there were many similarities in the basic language features and so it was a matter of drawing out the 1 to 1 mapping. For example, the syntax of for-loop, while-loop, do-while-loop, declaration of integer and character variable (excluding arrays) and that of some other constructs was the same in c++ and Java and so it was a matter of merely duplicating these constructs in the output program that would be generated as a result of running this program with another C++ program as argument.

Next, there were some features in C++ that could be implemented in Java but some modification would be required. But there were many other features that were extremely difficult to implement such as pointers.

Also for doing this project I needed to have a deep understanding of the class libraries and the inbuilt functions that provided in C++ and whether its exact or comparable counterparts existed in Java.

Java also included many features such as Interfaces and Packages, Multithreading and the most importantly the GUI based Applets. Even if a C++ code could be transformed into Java, there was a certain possibility that the above mentioned features of Java would not be implemented thereby underutilizing the functionality of the language.

Finally, after careful consideration, I decided not to go ahead with the project at that time. The important lesson for me here was that my feasibility study paid off and saved me a lot of disappointment which I would have felt had I blindly begun working on the program.

Quality Recommendations

One of my students has asked for recommendations on books for Software Quality Assurance and Testing. I will provide you my recommendations in a later post but I am interested in your recommendation of books and websites on these two topics. Thanks for your help! Later.

Exploring the Real Universe

With the end of the term and the holidays coming soon, you might want to know what to do with all that spare time.  Besides reconnecting with your family and friends or reading a great book, if you are looking for a low cost alternative, check out these paper models that NASA offers at (updated link) this location.

The link is daunting but it is worth browsing some of the model building activities listed there. 

Later.

Universal Access

Universal Access is the category in Apple's OS X operating system to tune the system for the hearing and vision impaired. Designing and developing software that can be used by the maximum number of people not only is the right thing to do but also makes good business sense.

A great web site to familiarize yourself with what is available is http://www.abilityhub.com/.

Do you regularly design and develop software and systems that takes into account Universal Access? Do you know of other resources for folks interested in Universal Access? Please share your thoughts with the group!

Later.

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?

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.