Keeping it in one’s head

A friend of mine recommended this text on why programmers work at night. Entertaining but still true.

But the blog post referenced  another interesting text written by Paul Graham about the necessity of holding a program in one’s head to be an outstanding programmer. I couldn’t agree more with that he says. I also agree with the corollaries that it is detrimental to treat developers as interchangeable parts in an organisation.

But what got me thinking was the fact that an architect must keep an entire system in the head. Where the programmer has the code as something tangible to base this mental model upon the architect has at best an abstract model and at worst only her own internal representation.
So for an architecture to be successful it both seems to be necessary that there is somebody who has the ability to internalise and reason about an entire system, and that the mental representation is possible to grasp in it’s entirety with (at least) one single mind. There are probably a lot of systems out there that fulfils neither….

List of ECU functions to determine

List of ECU functions to determine

 • fuel delivery • transmission shift points • valve timing • ignition timing, etc. sensors also monitor • oxygen levels of inlet air • oxygen levels of exhaust air • temperatures of inlet air • temperatures of exhaust • temperatures of oil • temperatures of coolant • temperatures of all other fluids like brake, clutch, transmission etc • sensors also monitors and controls functions of features such as ABS, EBD, EPS, ESP, SRS (airbags), etc. whichever applicable.

More on-line lectures on software architecture

I was discussing with one of my colleagues at the department if there were any introductory or summary presentations on-line about software architecture. I have already listed some on-line lectures about software archtiecture in the blog, but a quick search revelad some interesting ones:

• An Introduction to Software Architecture and the Risk-Centric Model by George Fairbanks. George is a an excellent lecturer and has written one of the best books available on software architecture. If you have the oportunity to discuss with him, take it. Too bad the sound is so bad in this video clip.
• Conscious Software Development: Architecture with Jeff Mckenna. Why not look through all parts in the series while you are at it?
• Software Architecture Document by Philippe Back. I don't know who this guy is, but he manages to convey a lot of essentials in 12 minutes
• SEI has a number of webinars related to software architecture. Unfortunately I can't get them to play on my computer, maybe you can?
• Out and About: Software Architecture with Simon Brown. A short clip with a view on what a developer needs to do to be an architect.
• Considering a Software Architect Career by Marc Ferrentino. A very short clip on what skills you need if becoming an architect.

MeeGo is out, what is in?

There has been some turmoil in the world of infotainment platforms. Intel has left Meego and have partnered with Samsung in Tizen. This just a few months after Meego 1.2 vas deemed GENIVI compliant. I have no idea if Tizen aims to be GENIVI compliant as well. But there are already some commercial platforms that are GENIVI compliant.

I have been involved in the Open Infotainment Labs, a project patially funded by VINNOVA aiming att evaluating radically different work methods compared to standard practice at most car manufacturers. We integrated the system in a car this week, 16 weeks after start of development.

AUTOSAR as open source

This might be the coolest thing I have seen so far: There exist an open source distributions of AUTOSAR!
And it's local to us here in Gothenburg, should I be embarassed for not hearing about this earlier?

Caveat: Note that if you intend to use AUTOSAR in a business setting you need to fulfill the conditions according to the AUTOSAR consortium.
After some e-mail exchange I now know that the open source AUTOSAR BSW software (ver 3.1) is available under a GPLv2-license.

Set-based architecture

I listened to a presentation from Durward K. Sobek II about set-based concurrent engineering, which is a development paradigm(?) from lean development (more precisely from Toyota Product Development System).

The original principle, as I understand it, is that a designer should work with a set of design proposals towards manufacturing and in the dialogue between what is desirable (form engineering) to what is possible (from manufacturing) iteratively narrow it down to a single design. He concluded the presentation with how one would start with this in the small and the advice was to present two designs instead of a single one the next time

It made me thinking about how an architecture is “presented” to the stakeholders, especially the developers. would it be possible to present two architecture proposals to developers and let them identify the constraints from their perspective in narrowing it down to a single, agreed, architecture.

Choke on cinnamon buns?

I wrote in a previous blog post about that I get upset about bad programming. I stumbled upon a prime example of bad programming from the excellent website Jävla skitsystem on that it was not possible to buy 20 identical cinnamon buns at 7-eleven at the same time because it crashes the cashier system and it would take 15 minutes to reboot.

I don't know what is most stupid? That there is an actual limit on the amount of goods you can buy, that the system crashes without recovery if you pass this limit or the fact that it takes 15 minutes (!) to reboot. First I cannot understand that the programmer was so narrow-minded he/she could not imagine these situations. Second I don't understand that the company delivering the system did not catch this in their testing. What kind of procedures do they have? And this system handles money...