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…