Rob's Software Engineering Logbook

Linux vs. Windows

In my last post, I hinted at a personal preferance that I have towards Linux over Windows. Much to my chagrin, my company has a certain level of Linux acceptance in the Software Department. If it was up to IT, we'd all be on Windows. Thank goodness it isn't up to them, though. They have enough trouble keeping the networks and e-mail servers up.

Linux has to advantage of Open Source that Windows may never have. This is one of the principles of the Simple Accessible Code and it offers the advantage of full disclosure to the end user over what the software is doing.

In my opinion, Linux is also every bit as capable as Windows. There are tools that compare with Microsoft Office (OO) and Adobe Photoshop (Gimp). There is a (pretty much built in) webserver (Apache) and out-of-the-box support for a wide range of programming languages (from Python to Java). Thanks to Mozilla, a superb (and widely accepted) web browser and GUI e-mail client are also available. More and more proprietary software is being released for Linux. Bash terminals are far more powerful than anything that DOS has ever offered.

But the world still uses Windows, and I still own a handful of shares of MSFT in my personal online stock account (mainly because of their latest generation of video game consoles). And in the forseeable future... Windows is here to stay.

Oh well... so much for "accessible code". :(

Robustness

A term in software engineering that gets tossed around quite frequently is "robustness". I use it myself when I want to compliment a piece of software that I feel adapts well to different environments and handles change well. Robustness is a desirable characteristic.

It is also a loaded term, though. Robustness cannot be quantitatively analyzed. If the requirements state that software should be robust - they would be rejected outright (at least, by smart software engineers), because robustness isn't testable.

Furthermore, is additional robustness something that separates the good software from the bad? Does the fact that Linux can be run on an assortment of platforms (x86, PPC, ARM, etc...) make it superior to Windows from a user perspective? Certainly, the majority of users "NEED" Windows to be productive in the modern business world (at least, they *think* they need it). In this sense, the more robust alternative is less desireable because the establishment of the alternative operating system transcends the Intel-compatible hardware it runs on.

[Editorial Note: I'm partially ignoring Windows CE & other "portable" Windows platforms. In my view, these targets never attained much acceptance. I have no data to support or refute this claim.]

I guess what I am driving at is that robustness is multifacetted. If a piece of software can be coded quickly and addresses a specific responsibility on a certain target operating environment then I would claim that it is arguably as robust as software that takes much longer to code, but handles multiple responsibilities in different configurations (that is, as long as the end user only needs the "specific responsibility" and he has the target operating environment available...).

When TOEs are scarce and responsibilities shift, though, neglibile work needs to be done on the system we said was designed for the general case, while a re-write may be required for the specific case. And the point of this discussion... at what point can the determination be made to put in the extra effort at the onset to design a general system? Doesn't the cost savings achieved by targetting the design to the specific need make it adventageous to skip true robustness in most sitations?

At this point, I am still unsure of the answer to this question... but I will continue to think about it.

[Editorial Note: In the beginning, I defined robustness as "adapts to different environements and handling changes well". I realize I spoke mostly to "adapts to different environments" in my entry. As a software engineer... this adaptability is a strong concern (in my view) for the products which my company makes. If you think this view is narrow-sighted, please let me know.]

Common Sense applies to Software Engineering?

Surely, it is foolish to believe that sense in the software community is common. There may be common axioms that provide a framework within which to develop... though adhereance to these is often the exception, not the common practice. But that is neither here, nor there. That particular view of common sense is *not* what I aim to discuss in today's Logbook.

The view of Common Sense we'll examine here comes from Mr. Thomas Paine circa 1776. Specifically, Paine makes a point related to the topic of complexity that has been addressed lately by the Simple Accessible Code (SAC) priciple proposed by Professor Gregg Vesonder, and tangentially by Using Simplicity to Control Complexity by Lui Sha.

In his pamphlet, Common Sense , Paine wrote:

I draw my idea of the form of government from a principle in nature which no art can overturn, viz. that the more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered; and with this maxim in view I offer a few remarks on the so much boasted constitution of England. That it was noble for the dark and slavish times in which it was erected, is granted. When the world was overrun with tyranny the least remove therefrom was a glorious rescue. But that it is imperfect, subject to convulsions, and incapable of producing what it seems to promise is easily demonstrated.

Absolute governments, (tho' the disgrace of human nature) have this advantage with them, they are simple; if the people suffer, they know the head from which their suffering springs; know likewise the remedy; and are not bewildered by a variety of causes and cures. But the constitution of England is so exceedingly complex, that the nation may suffer for years together without being able to discover in which part the fault lies; some will say in one and some in another, and every political physician will advise a different medicine.

For the sake of discussion in the software domain, which Paine obviously had no knowledge of, I would like to restate this in the words which make them relevant to software...

I draw my idea of the form of software from a principle in nature which no art can overturn. The more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered.

With this maxim in view I offer a few remarks on the so much boasted state of the industry (particularlly any project with SLOC in the MILLIONS). That it was noble for the dark and slavish times in which it was erected, is granted. When the world was overrun with assembly language the least remove therefrom was a glorious rescue. But that it is imperfect, subject to convulsions, and incapable of producing what it seems to promise is easily demonstrated.

Complex Source Code, (tho' the disgrace of the software world) have this advantage with them, they are maintained by a single organization; if the people suffer, they know the head from which their suffering springs; know likewise the remedy; and are not bewildered by a variety of causes and cures. But the source code of a MILLION LINE PROJECT is so exceedingly complex, that the developers may suffer for years together without being able to discover in which part the fault lies; some will say in one and some in another, and every software architect will advise a different medicine.

Therefore, I echo the words of Professor Vesonder, that, "developers of software systems should be able to understand the complete body of code in their systems." Clearly, this is not possible when SLOC approaches a million lines and when design documents for a single project fill a bookcase. When this happens, change is not only necessary, but it is inevitable.

Product Line Acquisition in the DoD: The Promise, The Challenges
by Lawrence G. Jones

I found this article to be a good read. One of the key points that Jones addresses is that to maintain a successful Product Line Architecture, you need to be continuously developing your Core Assets & your unique Products. He emphasizes that a major technical hurdle is positioning the Core Assets in a way that they can be reused seamlessly over and over again.

I tend to agree with this, because at the company I work for (which does DoD development) this is exactly one of the problems we face. I am actually going to begin attending meetings with representatives from two separate projects that have similar software components to develop. Both programs are reletively new - but based on the same legacy software.

Hopefully, by tapping into resources like the article by Jones, our two projects will gain guidance towards the concept of a Product Line.

Software Product Lines

During a previous class, we mentioned Software Product Lines. The idea is to design a core system and then when you want to add a new product you only have to implement the 10%-30% new customized/unique code.

Think of how Microsoft offers "Professional Edition", "Enterprise Edition", and "Home Edition". Or how Canon has the A80 (4MP-CF), A95 (5MP-CF), A520 (4MP-SD), A620 (7.1MP-SD), etc.. (that are all part of the PowerShot Product Line of digital cameras).

The problem is, in reality, by the time you identify a situation where Software Product Lines would be beneficial you've already produced at least three similar-but-different products, so picking out "common code" for the core is a very challenging job. If you are lucky, there will be a lot of overlap among the teams that created the three initial separate products and a lot of similar idealogoies were used. If you are unlucky, each product was slapped together more-or-less independantly and rectifying the Product Line will be as large a project (if not larger) as the initial development effort on the initial product in the line was.

===========

This is submission #1 for CS-565 (Computer Architecture) in the Spring of 2006 with Gregg Vesonder.

Web Browser Interface

There is a noticable distaste from the older generation of software designers towards using the internet as a means to deliver an application to a user.

I would like to state, first of foremost, that I feel that this belief is neither well grounded, nor supported by the recent trends in the industry.

That is not to say I don't understand why older developers (and users) feel the way they do. Certainly, not all web interfaces are created equally. In fact, the tools for such developments are fairly new to the industry (the production of a Java suite of webdev applications is analogous to the development of the first C compiler). As time progresses, the state of the art steadily creeps upward - and at its current point is it becoming evident that web applications are here to stay.

Let's consider a simple example... finding directions from one address to another. There have been steady increases in this since the proliferation of the automobile (and thus, a means and a reason to go from address to address).

Paper maps. Unfold them. Find your address. Find the index for the target address by its row-and-column. Locate the target in the designated grid location. Plot a course from point A to B.

Map Software. Install it onto your computer (did you buy it... or did it come with your computer?). Type in the two addresses. Have it plot a course for you.

MapQuest. First generation web application. Type in two addresses, and get a map and directions. Advantage over the previous: could be updated with new roads!

GoogleMaps. Second generation web application. Satellite / Hybrid view. 'Nuf said.

Let's consider something that probably isn't as accepted though, because I would bet that the number of paper-map-users who are also tech-savvy (no matter what the age) is dwindling.

Google now has a word processor that supports auto-save (it is called Gmail - it has 2+ GB of available hard drive storage space). There is a web based CRM tool available from Salesforce.com. Many SCM Tools (this is the area that I work in) offer varying qualities of Web Based support (from CVS to ClearCase).

That is just to mention a few. Now, the question begs... why a web application? Why.. desktop independance, of course. With a web mechanism I have automatic network support. I can get to my information from my cubicle, from my home (granted a firewall doesn't protect it), from a workstation across the country, or from the WiFi connection at the local coffee shop. [that said... from a coffee shop *without* a WiFi connection, I am SOL].

So, they are here. Their quality is vastly improved over a few years ago. Get used to web apps.

He Spelled HCI Wrong...

...was my first reaction to Prof Vesonder's CHI. Throughout the discussion, he used the phrase "Human Computer Interaction." Yet, in his slides the acronym was still CHI (which reminds me more of the chi-squared test that is useful in Artificial Intelligence).

Anyway, during my undergrad, I took a course called Studio Design in HCI with Prof Bill Hart-Davidson at RPI. Our project was to develop an intelligent design to make sense of all the possible permutations possible in the art of Music Interpretation. We designed an online portal (just created the specs... didn't write the code) where music fans could login in take part in moderated discussions on their favorite song, album, or artist. We provided lyrics and other artifacts that a person would want to create an interpretation. We provide support for (a) users who only care about reading the interpretations of others, (b) interpretters who want to express their viewpoint, and (c) critics who want to comment and moderate interpretations of others.

To create our design, we conducted interviews of some of our friends and fellow college students to understand what was desirable. We even directed some people to create an interpretation over the course of a week, and report back to us the artifacts they used, the circumstances of the interpretation, and the actual interpretation they had on a piece of music.

You can read more about our final project here.

Murphy's Law

So last week I was charged with the task of ensuring that the Training Room would be configured when a representative from Green Hills Software (www.ghs.com) came on-site to teach Integrity/Multi. I had to...

1. Make sure developers could run Multi from the training room
2. Make sure enough licenses were installed

My Preparation:

I had a license file generated last week for 50% more than the number of people who were in the class. I had tested a configuration which called for setting up a Remote Connection with a server which had the GHS software installed and configured. I judged that the remote server was powerful enough to handle the load of ~10 remote Gnome-supported connections + GHS over the network. The processor is a dual Xeon - so it stood to reason the it would have the power.

What Went Wrong:

I did not correctly install the training licenses. Even though the software gave me a "Success" message, it didn't write the new license file because the old one was still running a process and had a lock on certain files that needed to be modified.

I did not know that the Training Room computers were networked WIRELESSLY. Yeah... that slowed things quite a bit. No Remote Connection.

First Attempt to Solve Things:

Figured out how to correctly install the training licenses. Passed around CDs so people could individually install local copies of Integrity/Multi.

What went Wrong Next:

The license GHS gave me last week was for an x86 processor target while we were compiling for a target Simulated PPC board.

Second Attempt:

After a series of telephone calls to our support rep in Virginia and waiting for the license guys in Santa Barbara to arrive in their offices (by this time it was after lunch on the east coast - halfway through the first day of training), we finally had a viable system.

So, it is like the man said... Things will go wrong at the most critical times. Issues occur in bunches. Problems wait until large groups of users depend on their systems before occurring.

Good 'ole Murphy!

CS-565

Prof Vesonder mentioned teaching the Architecture course next semester. It is required for me... so I may just go ahead and pick the class for the near future. He is a good prof.

OO Programming

Function programming... what is that? We mentioned "favorite programming languages" and Perl was mentioned. That makes me shudder. As far as my knowledge of Perl goes... it is popular for certain things because it is versatile. In the early days of the web Perl was used for Form Processing. ClearCase leverages Perl to do certain things like task automation and triggers. Anyway, when a quick and dirty solution is needed my preference is batch scripts and throught the years Perl has all but disappeared from the web programming platform. Of course, this makes me happy because I don't like the archaic way Perl does variables and its human in-readable regexps.

C++ and Java are my languages. I've developed for a period in ASP.NET. I know SQL enough to make use of databases (I don't know if that counts as a language). I have a good understanding of XML (a markup language) and HTML (which doesn't count). I know DOS (on Windows) and Bash (on *NIX). I've dabbled in simple C programming (yay, Litec) and had two or three weeks of Assembly (MIPS) academically in college (yay, CANOS). Is that one language per year? I'm not sure... but technology is constantly evolving and I wish I had time to learn more. Especially Java web-based technologies. Those are sexy, now.

Topics mentioned yesterday:

Sharp Tools

We have a group at my company called the Software Technology Insertion Review Board which is responsible for reviewing and approving software tools (compilers, unit test suites, requirements, configuration management, etc). Employees suggest tools to the STIRB, which reviews the tool and then makes a determination of Preferred, Approved, Restricted, or Rejected. In theory, Preferred rated tools are the sharpest and most helpful - so when kicking off new development efforts guidance is provided to choose the best of the best.

On Meetings

I enjoy meetings. Communication is key, and meeting is a good way to communicate. Even if a meeting isn't for something directly related to me, I find it informative and always welcome an opportunity to learn about what others are doing. Also, though, I have seen people who were not expected to have the closest domain knowledge of a subject provide the best insights into certain discussions. You never know who is going to have the knowledge needed to most efficiently do what needs to be done.