Project presentation

I presented my project at the yearly Volvo Industrial PhD program conference last week.

How attractive it is to work as a software architect...

A colleague sent me this link from CNN Money about how attractive it is to work as a software architect. Go figure...

Hidden leaves

Philippe Kruchten wrote a very entertaining interpretation of Tao Te Ching from the perspective of an software architect. But besides being entertaining it has some very good insights into the nature of an architect, like the following:

The architect doesn't talk, she acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!"

Personally I'm more familiar with Japanese texts (more than 20 years of budo training) so I thought of interpreting the Hagakure with the same perspective (you can find a translation to English of the original text here).

Among the maxims on the architect's wall there was this one: "Matters of great concern should be treated lightly." A senior developer commented "Matters of small concern should be treated seriously." In one's project there should not be more than two or three matters of what one could call great concern. If these are deliberated upon during ordinary times, they can be understood. Thinking about things previously and then handling them lightly when the time comes is what this is all about. To face a problem and solve it lightly is difficult if you are not prepared beforehand , and there will always be uncertainty in hitting your mark. However, if the foundation is laid previously, you can think of the saying, "Matters of great concern should be treated lightly," as your own basis for action. (1st chapter, p. 33)

According to a senior developer, even a poor programmer will become substantial in the art of writing code if he studies by imitating a good model and puts forth effort. An architect should become substantial too, if he takes a good architect as his model. (1st chapter, p. 40)

The proper manner of architecting is nothing other than not being careless, but in this way one's design will be sluggish and stiff. One should go beyond this and depart from the norm. This principle applies to all things. (1st chapter, p. 48).

In carefully scrutinising the projects of the past, we find that there are many different opinions about them, and that there are some things that are quite unclear. It is better to regard such things as unknowable. An architect once said, "As for the things we don't understand, there are ways of understanding them. Furthermore, there are some things we understand just naturally, and again some that we can't understand no matter how hard we try. This is interesting."
This is very profound. It is natural that one cannot understand deep and hidden things. Those things that are easily understood are rather shallow. (1st chapter, p. 69)

On plagiarism and referencing

In the architecture course I'm involved in several groups failed the hand-ins due to insufficient referencing when using material from other sources. In academic writing it is allowed, and even encouraged, to base your writing on data from other sources so this in itself is not wrong, but it must be done according to strict academic standards
Worst case: Incorrect or omitted references is plagiarism, which is a serious academic crime that can lead to suspension from the university.

We will arrange a workshop for all 2nd year students on Wednesday 12 October 11:00 since this is a vital skill in all courses and the thesis projects. But in the meantime I suggested they should take a look at the following introductory material:

• A crazy Norwegian introduction to the subject
• A website from the same university on searching and writing academic papers
• Read especially about referencing
• A short (15 min) hands-on video lecture on referencing

The students don't need to use any specific style of references (Harvard, IEEE, APA, Chicago, etc) as long as they are consistent.

Seminar:Trends and challenges in architecting embedded systems

I will be talking at a seminar at the Royal Institute of Technology in Stockholm 4 November: Trends and challenges in architecting embedded systems.
Besides Martin Törngren from KTH and Jörgen Hansson from Chalmers there will be speakers from Ericsson, Saab Aerospace, Semcon EIS, Scania, and myself...

InfoQ: Model-Driven Development: Where are the Successes?

I found a good blog post about more experiences onmodel-driven deleopment at InfoQ: Model-Driven Development: Where are the Successes?. Read it and the articles mentioned.

I have also read through a summary of the study of Sascha Kirstan which was very interesting.Unfotrunatley i don't know if it is avaibale on thenet yet. However both he and Jon Whittle clearly stated that in practice the advantages with model based develoipment are not so much efficiency as quality. In practice the efficiency gains tend to be around 20-30%, not 3-5 times as one can hear among certain the evangelists. And the quality gains are in the same order.
But reducing the number of faults and errors with 20% impresses me more than reducing development costs with 20%.