Jävla skitsystem!

Pardon the Swedish!

The heading is actually the title of a Swedish book about how people can be stressed in a digital working environment. I think this is one of the most important books written about IT-systems and the problems they can bring on a personal level for the people who are forced to using them. Too bad is is not translated to English (yet?).
It is not a technical book, the primary audience are people using IT systems, secondly it is targeted at people planning and buying IT systems. It systematically lists 8 major stress factors and what can be done about them. Not all are caused by ignorant developers...
I think it is very valuable to read for people developing systems, so much I would make it mandatory reading for students in software engineering, if only it was published in English. There is some information in English, including a short slide presentation.

You can buy the book directly at the website or at major Swedish online bookstores.

You tend to favour the solutions you are familliar with...

When I talk to students about the role of the architect I always make a point of the architect must know when not to use a particular solution/pattern/style (the old "Kill your darlings"). Regardless of this I have seen examples when an entire class thinks that a 3-tier architecture is the best solution in a project because they took a course on databases the previous semester.
Likewise, when I talked about component-based architectures in a lecture and gave examples based on AUTOSAR, a lot of students thought that components was the thing, even if it complicated the solution for the developers and the benefits with components was not really relevant in the student  project.

This is not surprising since I am talking about students with limited experience to various problems encountered when developing real systems. But I also think this is a problem for professional developers as well, including myself. We tend to stick to what we know and don't reflect if what we know actually makes things worse than better.

Infotainment systems news

I have been more involved in development of infotainment systems this year. BMW demonstrates what they call ConnectedDrive and Ford updates their Sync system to what they call myFord Touch

Compared to the amount of information at the links above there is very little about the comparable 2010 Volvo infotainment system at the official Volvo website. Note that the BMW is just a concept vehicle, while the Volvo system in in production, and still has less information about it on the web.

When the car gets connected, it also gets exposed: Telematics and security: Protecting the connected car

Therer are some interesting news about some major players as well: Nokia announce a strategic partnership with Microsoft on 11 February. I have no idea how this will affect Meego and GENIVI. Time will tell...
On the other hand there was a lot of activity around GENIVI at the Consumer Electronics Show in Las Vegas. And GENIVI is based on Meego...

Research in software engineering

Researching software engineering is to study the artificial. Other engineering disciplines have "truths" that exist even if no humans are involved. The laws of physics that determine what is possible in mechanical and civil engineering are there regardless if applied when constructing a particular building.
Because of this I strongly believe that research in software engineering must be based on what practitioners do. I started to write professionals, but realised that a lot of important stuff in the world of software are actually made by amateurs (in the sense they are not getting paid to do it). And I also think research methods from the social sciences can provide great insights into software engineering.

A colleague of mine said that a good researcher in software engineering should have three base pillars to stand on:

1. A good knowledge of real problems that practitioners have
2. An interest in developing solutions to these problems
3. Knowledge and experience in evaluating the solutions in practical (real) settings

I have previously written about why I don't like formal methods. I think this is an example of where researchers tend to focus on the appealing solutions without a strong foundation in practitioner's problems or a thorough evaluation in practical settings. The most interesting solutions to investigate from a researcher's perspective are not always related to the most critical problems.

A short litmus test to discern if a researcher has enough experience of practical problems:
Describe the difference between a software process and a software project.