Time to Change

In the last year, many things happened in my life as a computer professional. I am writing no code anymore, I am now working as a safety, quality and requirements engineer. And I am glad about it. Let me explain, why.

In the last years, more and more the doubt came up to me if programming is really that what I am strong in and if it is what I enjoy. Even working in different companies, where completely different software were developed, in Smalltalk, Fortran, C, C++ and and means, I always had the feeling that I doing the same frequently. The problems of software developing repeat, the kind of solutions were well-known. I met many people, all of their own style, I had bosses which could never be compared, which was and is good. But the game - software development - still was the same from my point of view. Different in colors, in tones, in details, but in fact the same. No big progress, as also some well-kown mastes of software told. And I had and have so much more interests.



I know, this picture is not objective, my losing interest and my perception of software buisness have impact on each other and are not decoupled. But which is really the cause of what doesn't matter in consequence. So I decided to take a way in my carrier which lead me away from software development. That's why I am happy to work as I told above.

But what about the hobby ? On the private side, I looked at many programming langauges, read about software processes, design patterns and new approaches in the software domain. But the doubts described above take place here again. And at the same time, old loves came back to me: philosophy, electromagnetics, teaching electronically, the question how a set of neurons can think and get insight.

I've just finished the great book "Coders at Work" of Peter Seibel, which contains interviews with some big persons of the software buisness. And the part with L Peter Deutsch, which leaves the software buisness at some late point in his life, convinced me to make this decision: even as a hobby, software development will no more the objective of my hobby activities. This means, to be precise, to look at patterns, architectures, languages for its own.

Of course, I will program to let my new ideas come to life, maybe games, graphics, experiments. But the ideas are now in front, not the question what is the best language, the best approach. I make no attempt anymore to make software development better (one exception: requirements and safety engineering). That let be the task of computer scientists, which I am not. Just be creative, as long it is possible.

For this goal, Scala and Processing had attracted my interest, which both working with the Java environment. The Java environment has so much possibilities. Erlang is nice for experiments in the artificial neural network field.

But don't misunderstand: I will not close my eyes. I will look how technology and software science is going on, because to track and judge the social impact of new things is important. But my role will be from now that of an observer, not an actor of the computer science.

Holiday Project 1

As always, I planed some hobby activities for my holiday, because during workaday life there is always not enough time.
Project 1 was a drawing exercise in order to get more practice in line drawing and inking. Also, I experiment with colors and usage of Layout Markers. And here is the result (please regard it with a favor - I'm a learner :-)

I call this picture Experiment #1 : "Crossing". As can be seen, I am still fascinated from the idea of steam punk. It is an interesting task to think about which parts a steam man would comprise, and which are the characteristic building blocks of such creatures. I am very sad to have not more time to investigate this question.

One intention of this excerise was to work out to draw lines in different weights, and to get comfortable with the foundations of comic inking. Although I've done some progress, I have still huge respect to the professionals of the Comic Szene, it is really difficult to draw lines accurately ! As an result of this exercise, I am also starting to get used to Layout Markers.

It is always interesting to experience the relation of drawing to courage and resolutness. A line must be drawn without doubt or fear about error, which is also true for shadows or dark areas, or light spots. Here, only practice and strong observation will help ;-)

The next picture is planed to be carried out in oil pastels, but I can not say if my holidy is long enough. Project 2 is to create a game prototype in Processing, and Project 3 is about Erlang programming. So we'll see......

Observations from a mobile world

Some weeks before, I bought a 24 inch Full HD monitor with HDMI interface. The original plan was to make the first step to a Full HD television and to have a display device for the Sony PS3. The world of BlueRay calls me loudly ......
Todays monitors can be used nearly for all, thanks to the combination of the interfaces, including sound speakers. And of course, it can be used with a Mac, in my case a white MacBook. And whow, what a feeling ! Even DVDs, rich content websites, all looks so great !



Today it was the first moment, I used the MacBook again as a notebook, with it's own display. What a shock ! All is so small, no oversight, colors and brightness, no usability, no fun. But, hey, every day, my iPhone has to show me WebSites, provide me translations and the last news from Twitter or other news portals. And this display is much smaller. And it works for me so far. Seems like a contradiction, doesn't it ?

Well, in relation to the iPhone, another effect takes place: it works the better, the more the Apps or WebSites (more exactly: their iPhone version) are adjusted for small screens. And because there are many iPhones out now and in every-day use, you can really find WebSites in fine iPhone version (and this is a completely different thing as the crappy WAP things in the past....) which show, how it could look like to design an information or an operation interface for the capabilities of the destination device. Some WebSites could be used much better in the iPhone version because they show exactly what you want, and not more (advertisements....here blinks it, there are flash something, over there a color explosion, bah) !

Now, the current or near-future internet techniques provide so much opportunities for new ways of information and operation to the users. Have a look at HTML5, O3D, AJAX, the new JavaScript engines in modern browsers: the internet world is colored and rich as never before. And why should all the Web Designers not use this things and provide us with optical beauty, operational high usable experiences ? Display space is not a problem, look at the prices of >22 inch devices !

But my poor Mac is born in another world, as the idea itself to have a movable computer, too: its screen (and resolution) was great some years ago, today, it is catched between the iPhone and the big electronic color picture devices on the wall or on the desktop. The great user interface of an Mac OS can adapt to a big screen quickly, size can be turned to usability at once. The other direction is full of restrictions. Mac OS is not an every size auto-adapting paradigma system, as all software systems I know so far.

In fact, my observation is this, based on one year usage of the iPhone, 6 years of (Apple Mac) notebooks and now a 24 inch 16:9 display: size doesn't matter, if the informational and operational design reflect and support the natural way of use of the device.
(Important remark: the WebBrowser and the native Operating Systems converge quickly, therefore the following is stated only in respect to the Web, but is valid for OSes, too).
Because the new Web technologies provide a big toolset to implement nearly all ideas, and because the Web Browser is a potential flexible thing (it looks like a simple text file tells him to look like), I expect from the UI designers to reflect and to use the nature of each possible category of display device. You *can* use a iPhone, a Netbook, a Notebook and a wide Cinemascreen with fun and operational value, *if* you adapt not only colors, text font etc but also the paradigma of visualization of information and interactiviy !

Please designers, meet the challange, use all your creativity to give as an interface for every device, and be aware, there will be more in future: tablets with touch screens, mini projectors and gesture recognition............. That would be great, and more, it would take us to a real flexible and real mobile information society :-)

Steam Gestalt

At this time, I am productive in drawing. This is cool, because in the life of Software Engineer or even Software Architect, the creative part of my person has no possibility, or at least not enough, to come out. If my information is true told from many people, then I should compliment Google on let their Software People work for some fix part of the whole time on their own ideas. I am shure that gives much value back to the company, even if this benefit maybe not measurable and described by any numbers.

But back to my work. One of my friends told me about a game embedded in a fictive world where is no electricity, but steam instead. I am very excited about this idea, so that I had to draw a gestalt at once (originally I want to ink it, but unfortunatly there is no time in the moment).

So It seems, that I got an big interest on designing gestalts, their equiment, and gesture. Of course I am far from perfect, I need much more experience. But I have a sketch block now, and where ever I got some idea, I will take the pen.

UML in the Functional Programming world

UML is a well known standard notation in the context of objectoriented design and programming. It allows to define classes and their relationsships. It makes it possible to display Use Cases and the Activities performed for them. They way how objects interact together can be visualized in more than one way.

The problem is: it's all about objects. But we are in the age of a new rising star: the functional programming. Here we deal only with functions. There is an input, there is an output, no state. Just a rule to map the input to the output. No behavior. Just a chain of input - output mappings. It seems that UML doesn't fit very well. Some languages interpret functions as objects, but in the end that doesn't help. Functions are a mathematical construct, they are best defined in the way we learned in our mathematics education.

Let's go a step back and ask: what is the goal if we use UML ? It is used during the design phase, so one goal might be to communicate architectures. An other goal might be to write down design elements of the software to build, on a level which allows to use abstractions and to suppress unnecessary details. Of course, abstractions and communication is not only about data structurs, but also about what is done with this data, and by which entities. And in the end this is the nature of using UML: finding out and document what is needed, what happens, and what is get.

Ups. Thats reminds us of functions. There must be something wrong. So, again, one step back: how should we document software ? Actually, the main purpose of any software (which is not used for controlling some device, because their nature is just to be an extension of mechnics) is to provide information. Information aggregated from other informations, as well as calculated, filtered, selected and transformed information. The nature of information is to be data, which have an intention: a question to answer, an goal to achive. If we describe the data and their intention, i.e. the information, and their origins and lifecycle, we have in fact described what a system is. It doesn't matter if the technical implementation is done by functions, or by interacting objects. Thats a matter of the detailed technical description, which is important only for a small set of people (and it has to be decided for every project if the code is the documentation or any detailed UML diagrams or equations are needed). Or in other words: it is in matter of level of detail.

Let us note two additional observations:
1) The data comming from or going into the real world can be modeled better by objects than functions.
2) The context as part of the system environment is the source of intention (what will I achieve, why I do something).

Bring this all together, we can see that UML helps to document the data and their intention and their lifecycle via UseCases (maybe annotated with activity diagrams, for context and intention), Collaboration diagrams (for lifecycles), Class diagrams (for the pure data). In this sense, UML should help document software independently of the programming paradigma used with a sufficient level of detail for the most cases. And if more detail is needed, UML is appropriate for the OOP and mathematical equations for FP (and PI calculus for heavy concurrency systems).

Requirements: The Picture of Software

As we all now, all software development starts with the wish or the need of a customer. The customer has a problem, that he (or she) wants to solve. Then it might be, that the customer has also the idea of a possible solution in mind. "If I had .... I could..." or "if I get ... then I could" and other signs of such ideas is well known.

In most cases, this idea is embedded in the domain of the customer, it adresses data which are key parts of its domain. Or it is related to actions performed in this domain. In either way, it has no technical nature. (It may be that the customers domain contains technical things, computers, machines, but then they are part of the domain as all other and therefore are natural to him.)

Then there is the other case: the customer has no idea, just a problem. But then, he has at least a goal, which means there is an idea of a situation which he (or she) wants to achieve.

Now it is our job as software professionals, to draw a picture of a system, which, beeing embedded in the customers world, would solve his problem and let him reach his goal. If we have this picture and it its approved by the customer, we could build the system and the customer will be happy.

That sound's easy but it is not. The customer has a sound picture of his domain in mind, but a weak imagination of the new system (well, he is no technician...). And this new element must fit in. The software professional on the other side has a strong imagination of "his" new system (what a wonder...), which must be embedded in the - from his point of view - weak picture of the customer domain. It is easy to understand, that the weak parts are in danger of beeing forced to fit and therefore getting distorted. Now the problem is obvious: all parties have different parts of the picture that are weak. In consequence, the resulting overall picture of the customer and the software developer will differ necessarily.

We know, that an iterative process for software development is the best solution. By creating prototypes and mock-ups, things that can be "touched", the picture comes out of the head of all parties and can be experienced directly by each other in early project stages. And because it is not feasibile to come through this in one step, many steps are done, where ever news prototypes and mock things display and stress different aspects. But in the sum, over all iterations, the picture should become more and more equal for all parties. The picture of software becomes clear and sharp, we've got consensus. (BTW, this would be the planing guide for iterative processes: touch all constitutive aspects at least one).

Sounds easy. But software is developed in teams, and not all members of the team can talk with the customer directly. And more worse it is not always possible to talk with one customer, there may be many stakeholders. So the picture in mind must be communicated via documents, but how ?

To find an answer, think about a patchwork image, and the task is to fill a empty place. So the first question is: the shape. Which shape I need to fill ? Related to our software project, this would be the interfaces, logical, functional and physical. Then, one might look which colors would match, then which things the part should show to continue shapes or patterns of the whole picture, and so on. That means: for communication via a documents, one should take certain point of views to the domain and the new system, explain them and why the part fits in the hole. One chapter one point of view, with the goal, to come close to the picture of software.

If all important aspects are described like this, then there is a chance that many people which read the documents become a more ore less comparable picture of software (and its environment) in their minds and the right software at the end.

BTW: There are people, which can design such missing parts of a picture handling all aspects at once - we call them artists.

Started my work on Philosophers Erlang SVG Server

It is time now to start an project which is in my head a long time: the Philosophers Erlang SVG Server. A good friend helped be to get through the kick-off and to realy do it, so now I have set it up as an Google Code project. The beginning is always the hardest part, and it is done.

Details I am writing in the wiki of the Google Code. For now, there is not much to read there, but I hope it will grow steadily. Also, there is not much code yet, but Eclipse is set up with Erlang plug-in Erlide and direct contact to the SVN of Google Code, so, it can really really start.