License to Code

One issue that may affect all of us professionally is whether software engineers should be licensed. In response to another student's post, Rafael Polanco provided a case for software licensing. What is your opinion on licensing software engineers? Later!

Rafael Polanco's entry:

These are excellent questions and ones that must be addressed. We are seeing more and more applications for software in our daily lives. To me, the future shows us running our homes via the internet using handheld devices. We would remotely control our homes by settingthe temperature, opening and closing windows and shades. Maybe we would start cooking so by the time we get home, the food is ready. We would view moving images from our office or train, etc... These things can be done today!

Software is being applied to health systems more than most people think. Not only do MRI's have to use microprocessors running software but operating room robots have to as well. There have been cases where the doctor performing the operation was on the opposite coast of where the patient was. I believe in these cases, they used dedicated lines of communication, not the internet.

Also, some of New Yorks' borough of Queens' traffic lights are dynamic. Depending on whether the US Open or The Mets are playing, the traffic lights in most of the major Avenues and Boulevards in Queens change their timing schedules. The city likes the way this have been working so much that they would like to roll this out to every traffic light in the city!

The point is that we are relying more and more on software to continue the advancement of technology in many fields. From health systems to civil engineering, software is showing its face so something has to be done to make sure the proper procedures and sound practices are used in their development. In the Dental field, doctors must take state exams to legally practice in that state. I have seen want-ads for software

programmers where the minimum requirement was that the candidate have a high school diploma.

I think that the field of software engineering has to start the creation some kind of licensure in conjunction with the law that allows you the privilege to develop and/or design software systems based on the field for which it is to be applied. I think this is the only way to force more companies to use software engineering. To call yourself a health systems software company, you should have to pass inspections. There are standards out there that are recommendations and to date the only field I know that uses them are in defense and aerospace. This is because the user, the US Government, mandates the use of these practices or else the company gets no contract.

Game Strategy

I have been a big proponent of learning from the computer gaming industry. Many industrial applications are boring and unnecessarily complex. It is difficult to make something simple, entertaining and comfortable. Ross's post provides some great heuristics for making the whole human computer interaction enjoyable. We both would be interested in your thoughts. Later!

Ross Arnold's post:

As I've mentioned in my other log book entries, I program many games for fun and for my eventual goal of running a small game company. I long ago came to a conclusion while coding games with respect to user interface - EVERY aspect of a game should be fun, not only the playing of the game. If 6 menu screens need to be traversed before the game can begin, then each and every one of those menu screens should be fun to look at, and fun to use. The buttons should be pleasurable to click on, visually appealing, smoothly functioning, and easy to use. I feel that game players often don't realize the joy they take in traversing well-laid-out game screens, instead focusing thoughts on the gameplay itself - but the joy is still present, and it still pulls people back to play a game again, even if they don't always consciously realize.

The same principle applies to my current project at work - a pocket PC used for mortar ballistic calculations. Since the screen is so small, the layout of the buttons and edit-boxes is even more important than it would be on a desktop or even a laptop computer. If a soldier is crawling along a trench in the desert, pulling out his pocket PC and plugging in a few calculations shouldn't confuse him or cause him undue stress because of a few poorly designed dialog screens.

Two web examples also come to mind: MSDN and google. If I type 'vesonder cs540' into a google search, Software Engineering Class Page instantly pops up in clear view as the 4th entry on the page, then one more click and I'm right where I want to be - it's quicker than using my bookmarks. MSDN, on the other hand, seems to be rather poorly organized (it might just be poor searching technique on my part, but isn't that what library organization is meant to counteract?). I must have spent at least 30 minutes straight the other night searching MSDN for the EULA for MS Visual C++ .NET Standard to see if I could use it to develop and publish progams for profit, and I was never able to find it (I don't suppose that you happen to know whether VC++ .NET Standard, as opposed to Professional which is $900 more expensive, can be used to publish?). In my opinion it was just absurd that the EULA wasn't readily available on the page that described the .NET software. I've had many troubles searching for similar things on MSDN, often items such as downloads that I am absolutely sure are present because I've seen them just moments earlier accidentally on MSDN, and then can't get back to the page I saw them on even if I type exact words that I saw on the page, or exact file names, etc, into the MSDN search engine. If I ever design a website for one of my games, which I'm sure I'll have to do at some point in the near future, I'm going to make sure that I have everything organized, readily available, and SIMPLE, so that I don't have people like myself bumbling about the site, lost somewhere in the bowels of cyberspace.

More Testing in College!

Molly Campbell's entry on testing makes a great suggestion for how we can improve our Computer Science classes that emphasize coding. She asserts that testing is not emphasized in these classes and makes this observation: "Testing was something the professor did to grade your program, not something you had to focus on."

Molly is right on the mark with her observations. Software engineering practices should be used not only in industry but also in academics. Good software engineering practices should begin in school, if we have any hope of using them in history. Do you agreee? What other software engineering practices were ignored in your computer science education? Later!

Molly Campbell's entry:

As we discussed the importance of testing during lecture, I was reminded of the lack of project testing that occurred during my undergraduate studies. The absence of testing is ironic after reading how Brooks says that testing is the most important part of a project.

In school I experienced the opposite, spending almost all my time on coding. Some professors did stress the importance of planning, but I don’t ever remember anyone emphasizing testing. Granted our school projects were of a smaller magnitude where it was easier to get away with a lack of testing, but you’d think if half of your time should be spent on testing as Brooks suggests, that it would bare more weight in an academic setting.

School projects usually ended up being finished during crunch time so you were just so excited to get it done that you hardly tested it at all. Testing was something the professor did to grade your program, not something you had to focus on.

The importance of testing early and often could easily be stressed more even on the more simple projects done in school. Perhaps if it was emphasized there, it would transition to the workplace easier and we’d have more successful projects. It’s an interesting concept.

Now that I’m in the workplace, I realize that more people understand the importance of testing, but there are still similarities to my school experiences, especially when a project gets behind schedule. There is definitely still a crunch time and it seems like testing is what gets sacrificed. Even on my current project, it looks like regression testing is going to be cut in order to meet the schedule.

I think by testing early and often we will help make sure that more of our effort is spent on testing and hopefully we will benefit from getting early feedback. We should also remember the importance of testing when planning the schedule so we allot sufficient time for testing. Well tested programs will definitely provide the best results.

A dimension not only of sight and sound but of mind.

This next log book entry focuses on communication. During the class we discuss communication a lot. Brooks' Mythical Man Month is all about communication, Multics discussed the inhomogeniety of technical understanding and light methodologies such as XP stress interpersonal communication. Ed's entry squarely addresses this issue and how difficult it is. Later!

Edward Gilsky's log book entry:

Having nearly completed the first course CS540 in the Quantitative Software Engineering MS being offered by Stevens Tech, I find myself wanting to believe that some of the material we have been introduced too might actually work and make my job easier, however, my mind keeps going back to something one of my instructors said to the students in a class I was in a long time ago.

In 1982 I was taking my third programming class for my BS in CS at Florida Tech. The class was COBOL and the instructor was a nice guy who cared aboutwhat he was teaching and his students, so he would often discuss the "why's" of what he was saying instead of just the "how's". A student brought up a problem he was having with another instructor who didn't like the way he had coded something, even though it seemed to work. The student was frustrated because he couldn't get across to the second instructor why he had written the code the way he had. He asked the COBOL instructor how to make it clear, and the COBOL instructor said "Never defend your work". That's all, just "Never defend your work, your just wasting your time". That didn't go over to well with the class, we were very defensive of our creations and generally took it personally when someone criticized them. We decided that the COBOL teacher was just old and tired, much like the language he taught.

Over the years I began to learn that he seemed to be absolutely right. I still couldn't figure out why, but nine times out of ten, when I tried to defend (or even explain) what I had done and why (in particular to

managers), the end result was that things were worse than before I had done so. Eventually I learned to avoid explaining what I was doing, even though I didn't understand why it was necessary to do so.

After some years more I considered that maybe the problem was not the people I was talking to, but me and my inexperience. With more experience I might be able to do better, so I tried again. Didn't work. Things I said just disappeared into the void or mutated into utter nonsense. When something I said made its way back to me, my general response was "I said what!? I don't even understand what that means!". It bugged me that I was apparently completely incapable of communicating this particularly important piece of information, when in all other parts of my life I seemed to be able to explain myself fine. So I thought about it some more and decided, it's not my fault. When a developer speaks to a manager (and sometimes another developer), no matter what the developer says, it comes out as babble. No matter how eloquent you are, no matter how well you have your facts together, no matter how well you know the subject matter, all they hear is "Wa wa wa wa wa" (Charlie Brown teacher noise here) because, in the end, they don't have the slightest idea what your talking about! So, they think "I didn't understand that, therefore, it didn't make any sense, therefore, this person doesn't know what they're talking about, therefore, they're incompetent and trying to snow me". I've decided, once again, "Never defend (or explain) yourself, it's just a waste of time". Maybe even to include all this process stuff.

Is this just my particular twilight zone or do other people experience it too?

Change Management

In class I discussed the value of having a transition agreement when you are required to complete items on an old project while starting a new one. It is in the best interest of both the old and new projects and their management and, most importantly, it usually saves the Developer's sanity. Julie Robbins provides a great case study of what happens when you can't get this sort of agreement. Anyone else have similar experiences? Later!

Julie Robbins entry:

In class we have discussed transition documents that allow the developer to cleanly move from one task to another. I think this is something that every developer has experienced and it's exactly what I needed in my last job. I was the team leader and main developer on a project before my family and I had to move to Florida. My company had an office there so I worked remotely on the project for a while. The powers-that-be thought it would be great for business if I began work on a new project they were trying to kick-off there in Florida as well.

So I began designing an application, working from a set of requirements created by someone else. I soon learned that the requirements didn't have the buy-in from all the stakeholders and that the IT support at the site was ineffective. As I tried to meet with the customers and determine where the holes were, the original person on the project who wrote the requirements left the company.

So there I was, in a chaotic environment with way too many variables that were out of my control. And.. I was still supporting the previous product by visiting customer sites in Florida and flying back and forth to meet with my old team to discuss new development.

Although a transition document would have been ideal in this situation, I'm afraid that in reality the voice of politics did not allow it. Management in both locations was in competition for new business and visibility to the main office. I didn't know it until too late but I was caught in the middle with no hope for an easy way out. Over the years, I've been able to see it clearly happen to others as well. The developer is, more often than not, the powerless pawn in the political side of software development.

Is it safe?

As the semester ends log book entries are picking up. Mike Bonastia in his entry asks the question of whether Windows 2000 is appropriate for safety critical applications. I suspect Mike may get some interesting comments! (The title of this entry comes from a line in the movie, Marathon Man.) Later.

Mike Bonastia's entry:

One issue that comes up in industry deals with what type of operating system should a safety critical applications run on. There are operating systems that are commercial off the shelf that guarantee that safety (safety certificates), but they can be rather expensive. The other cheaper options are to go with a UNIX flavor or a Windows flavor. UNIX systems offer a variety of customizable features that can help make a safe environment. Window systems are less customizable but are a cheap fast solution. Microsoft will not guarantee that it is a safe environment or at least they won't support or claim responsibility if something goes wrong. Is it possible to make windows a safe environment for a safety critical application? Some simple practices could be:

- Not allow the user to have access to the OS.

- Have only the one application running.

- Disable services that are not going to be needed.

- Use a wrapper or a piece of middleware that will isolate the application from the OS.

With this in mind, I am interested to see how people feel about this issue(i.e. WIN2000 being used as an OS for a safety critical application).

Another Sharp Question

C# certainly seems to be a hot topic these days. Ankita Parikh, a student in the web version of the Intro to Quantitative Software Engineering course, has posed this great question. Your help and feedback is appreciated. Later!

Ankita's question:

I am currently working on a project for my senior design class and we are using ASP.NET and C# for the project. My question is whether you knew of any formal coding conventions that I could use for these languages. I know there are coding conventions for C/C++...I've found hungarian notation and several others. But they didn't really help me. I am not even sure if there is anything available for .NET and C#.

Use Cases in Testing

This blog entry is from Pawel Wrobel, a current student in my CS540 class, Introduction to Quantitative Software Engineering at Stevens. It is a great illustration of how versatile use cases are. I hope you enjoy it. Later!

Use case modeling is not only a good way to collect and analyze functional requirements of a system but it also greatly facilitates testing. On my previous project our group was responsible for elicitation and validation of requirements for a new system. We decided to employ use case modeling. Preliminary requirements were obtained from our subject matter experts and use case model was created. Consequently the use case model was presented to the prospective users. We found out that users really liked working with the use cases, as they were easy to understand and they could play out different scenarios of their interaction with the system. After numerous iterations we arrived at our final use case model that we included in our requirements specifications and submitted to our contractors for further development. At the same time, based on the use case model, we began developing our test cases for formal acceptance testing.

Star (language) Wars

This is a logbook entry from Minh Tran, a student in my Introduction to Quantitative Software Engineering Class. Logbook entries, for readers who have not been in my classes, are reflections on software engineering topics done on a weekly basis as part of the course requirements. I feel that maintaining a logbook is an important mechanism for learning over your professional career and want to get my students in the habit of maintianing one. Minh was responding to an entry I provided in class that suggested that one sure way of getting develolpers into a debate is to ask what their favorite programming language is. We discussed reasons why developers felt that way which included issues of support, relative performance, first language learned ... Minh expands this discussion to issues of Microsoft's support for languages and asks for some input from our readers. Later.

Minh Tran's logbook entry:

In class 9, Professor gave us an entry about "Star (languages) Wars" : C++, JAVA. Fortunately, I had an

opportunity to work on JAVA, HTML, ASP, SQL on Microsoft, and C++, MQ Series, Oracle on UNIX/LINUX for the last couple of years. Currently, I work on new projects that use Visual C++6, and Access for database. 80% of coding is done and being unit tested. The software release date is near. As I know of, Microsoft stopped supporting Visual C++ and has a new tool Visual.Net using XML & ADO.Net for data access. Few weeks ago, one of the projects' leaders mentioned about the new tool to me, he wanted to migrate standard C++ to .Net. I did not know what to tell him, because I have no knowledge about .Net, neither the team.

Should we stay with Visual C++, or use the new tool .Net or JAVA ?

Your inputs are greatly appreciated.

Far Out Architechture

This entry follows up on a previous post with regard to NASA's efforts in software architecture and design (Software for the Stars). I am now reading through the articles referenced and found a gem by Dvorak, Rasmussen, Reeves and Sacks, Software architecture themes in JPL's mission data system. You can get the paper here.

This paper is a great discussion of an architectural approach using a state-based architecture. The authors detail their efforts to decrease coupling between modules through using coordiantion services and the examples they provide are easy to understand and serve to illustrate nicely the architectural point emphasized. They also introduce in the paper 13 themes of the architecture describing each and illustrating by example. Some examples of these themes are: construct subsystems from architectural elements, not the other way around; system state and models form the foundation for monitoring and control; express domain knowledge explicitly in models rather than implicitly in program logic; for consistency, simplicity and clarity separate state determination logic from control flow; design interfaces to accommodate foreseeable advances in technology etc. All of this is then modeled in the UML.

This paper is highly recommended. I am definitely using it in my architecture and design class and, since the writing is so accessible, I may even use it in the intro to software engineering class. If any of you get a chance to read (its other nice attribute is that it is short, 6 pages), I would be interested in your comments. Later!