This is kind of a late notice, but on Tuesday the 10th of May, I will be holding a brief ASP.NET 2.0 presentation in Malmö, Sweden at the company I for: Dotway. A collegue of mine is also presenting Windows Forms 2.0. If you understand Swedish :~) and if you are interested you are much welcome. You can read more about it here.

Today, I ran across several disturbing usability issues using the version handling tool ClearCase. I was to deliver some bug fixes I've made in an older version of an application in a developer stream to a newer version of the application in another stream using the deliver to alternate stream operation in QlearCase. This is certainly a very valuable operation and since this was the first time for me doing so, I was full of steaming anticipation. I thought, "...just a few clicks and I am home free. No cut 'n paste the ol' fashion way. Hell No!"

I had three bugg fixes in the old version. I figured that I could select these three specific work orders, click on deliver to alternate stream and voilá: I'd get some nice merge code screen shoots in which I could select the code to deliver to the main integration stream in a simple way. I've seen and used the merge view in ClearCase before so I knew this would be a breeze.

First issue: ClearCase would not let me choose only the three work orders that contained my bug fixes. I had to pick all work orders, including some other irrelevant stuff that I didn't want to integrate to my main integration stream. Ok. Fine! I'll do so imagining some extra clicks here and there in the merge view.

Some ~250 click procedures later in the merge view, an increasing awareness arose that something was probably deadly wrong. I had been changing some Controls properties in my user interface which meant that many .resx files had been changed. Further more, I seem to have had my Visual Studio.NET project files checked out for either adding or deleting files. Ok, I'll take the pain I figured and continued to click away... All of such changes would be button number 3 anyway (see algorithm below).

Some ~350 click procedures later my brain, set to 'algorithm mode', started looking for a way of improving efficiency. I define the clicking procedure algorithm accordingly:

Step 1: Move the mouse to the "arrow" button.
Step 2: Click!
Step 3: Move you mouse to either button labeled "2" or button labeled "3". Decide this based upon the merge view. Mostly 3.
Step 4: Click!
Step 5: Goto step 1.

Anyone who has performed this algorithm a couple of hundred times knows that your arm gets tired from moving the mouse. It would be much nicer finding a keyboard shortcut for at least one of the clicks. And, voila! There it was: Alt + "Arrow right" for clicking the "arrow button". Now, most keyboard I know of, there is a certain distance between the 'Alt' key and the right arrow key approximately consisting of some 20 cm. If you don't play the piano or otherwise is skillful at playing the classical guitar, you will have to use two hands. It doesn't take an Einstein to figure out that my algorithm is worth crap with this approach. I still would have to move at least one hand back and forth. Issue #2 as you might guess.

Light bulb!!! Unfortunately it didn't come from me :o) but from a colleague of mine, Mattias Ask: "Put a heavy something on the Alt key." Tada! My heavy wallet finally found a superior purpose other than containing receipts and, thank good, heavy coins.

Damn! The speed is up! 400! 500! 600! 700! Heavens! Does it ever end? A growing suspicion in my mind tels me that it isn't and that I should chicken out and abort. Yes I'll do so! I dare no longer. Just think if something go wrong and I have to undo some 1000 click procedures manually in the code.... Oh, Abort, abort! --- Hey! Wait a second... There is no clear way of aborting this thing and perform a rollback operation. Guess what the third (!) issue is? :( Coming to some Rational sense, I realised there was never any risk of having to undo a thousand clicks manually. And I started to click away again.

Well, I did give up anyway. :o( Even though not so time consuming I never was much for repeating dull tasks. In the end I did find a way of aborting: just closing the merge views as they appeared finally led you to a button with some kind of abort labeling (forgot the exact name). Doing so makes it possible to continue at a later phase. Ok, so I tried that just to see if it was working. Sure enough it did. But ClearCase got confused with three of my remaining files and refused to accept my choices (button "3" off coarse). I guess that makes my fourth devastating issue. So in the end, after some perhaps 1000 click procedures, I ended up with a complete failure. Here we go: back to the good ol' cut 'n paste. Someone recalls my previous blog about technicians sometimes preferring to do things as done before?

I don't like this at all. It seems to me that this should be working, if doing it right. And the fact that it didn't bothers the hell out of me. The most important lesson would off course be to have only one bug fix as one work orders to deliver to an alternate stream. But since I always would have to do this merging graphically there is still one problem as I see it. The main stream containing the later version of the code has normally some continued developed code (that’s why it is the next version, ehh!). And if a delivery from the developer stream to the integration stream has to take place, there normally should be lots of differences between the two versions. In essence meaning many click procedures. I would very much like some ClearCase expert to give me some answer to this question and some advice of 'best practices'. Hello world! Is anyone reading?

When I came up with the blog title I figured that I would explain in some more detail what I meant in one of my future blogs. And when I experienced one aspect of what I mean so clearly on a workshop this week, I thought I'd take the opportunity to write about it. I better warn you that this blog is of a more philosophical nature. If you are not in the mood for this you better stop reading right now…

But before this, as a small taster I would like to add a personal background which might illuminate my standpoint further. Some 6 years ago I acquired a Master of Science degree in Electrical Engineering. Such an educational program includes many different technology areas; A big package of mathematics, physics, electronics, computer programming, etc. All of these technology areas share one common approach of how to pass a course examination. Some problems are to be solved in a preferable way. Looking back, I remember facing the following questions for each new course: What is the problem, where is the knowledge that helps me solving the problem, and finally how do I solve the problem. It is obvious that by repeatedly dealing with these questions in various technology areas you train the ability to extract important information, analyse it in a correct way, and then finally act upon it. The essence of this is that the approach is general no matter what underlying technology is being used.

Looking back now I am happy that I have learnt a technique of how to approach these questions. But I feel that often there was one question missing: why are we solving this problem in the first place? During those years of studies, the answer was intuitively there most of the time and I didn't even have to address the question. But in real life, and perhaps especially in the software development community, I feel that the question why is so much more important, and unfortunately also sometimes difficult to answer. Because when we building a “machine” that in some way or another is to help people, the ground base for its success is all about the interface between the man and the machine: MMI.

Now, I am not saying that programmers tend to forget the important question of why the software is being developed. On the contrary, I think most programmers are very interested of what the purpose is for their developed code. But I do think that we tend to narrow the field of possibilities by immediately thinking in terms of how we should solve the problem. In turn I believe this limits our creativity in terms of HCI aspects. I further believe we tend to stick to solutions that we have implemented before, that we know of and thus also are in control of. Certainly this is valuable since reusing old ways of thinking is both time saving and less prone for failure. But the question the developer always must ask himself is "Are we really meeting the purpose of the software". In essence: Why do we develop this software?

During the workshop this aspect was so clear to me. I held a presentation and demonstration for a group of people of a software application that I am currently involved in developing. This application is a bit special since it is to be used and integrated in many other applications in an enterprise environment. This is probably the worst case scenario for a program since it most definitely will mean that different and possibly even conflicting requirements are set for the application. Now, at the workshop there was me and some other guys from the IT department present. The rest of the people were all either business managers or business analysts as representatives from different application teams that were to use the demonstrated application. None of them I believe have a technical background, but all of them had a very in-depth knowledge of how their applications are to be used and implicitly and ultimately also why it is to be used. During the day, we were all discussing new future requirements of the application. As each new requirement was discussed, I could not help to think of in terms of how it could be implemented. This in turn might have narrowed my mind in terms of end user possibilities.

Now, I believe I am a true-minded technician. And for me not think in terms of possible solutions when I hear a requirement… Would that not be like waving a banana in front of a monkey and asking him to look the other way… ? ;-)

So. In conclusion: I am not saying that we technicians should not think in terms of “how to solve things” when we hear of new requirements. And perhaps thinking in terms of how to solve things should always be our role in the process of creating the perfect software (Is it doable?). But I believe we should always try to be as open minded in terms of possible solutions as possible and that we should have a huge amount of respect for people with better knowledge, understanding, and experience of dealing with this very question. And we technicians should certainly never believe that we understand the reasons for the existence of the software better than anyone else just because we know the details of its current behavior better than anyone.

Having written all this, I have a feeling that perhaps I have just stated something that is evident for all people, including technicians. But I’ll think I publish this blog anyway. Perhaps I come back rereading it in five years and laugh at my thoughts at the time. Or perhaps not…

My first entry in the blogosphere. Don't know if this initial blog will be my only one and if I am to become one of these one-time blogger wonders out there. Neither do I know if softwareandwhy.blogspot.com will become my permanent webadress, but I'll be sure to leave a reference to my new place if I change.

So here I am folks! For everyone and especially noone to read.