I’ve returned from my South Africa trip two weeks ago already, that gave me enough time to get used to the Dutch cold again. While it is still quite fresh in my memory I would like to take the opportunity to write a bit about my experiences at the Espresso workshop. First of all, I would like to thank the Espresso group, and especially Derrick Kourie, to be so kind to organize the workshop and invite me. I had a very warm welcome; it was great being back in Pretoria for a short one-and-a-half day.

I got many reactions on my (short) presentation about abstraction and design foundations, and to hear from students that they enjoyed the talk, finding it interesting to hear from someone out there in the field was very nice. Especially the fact that I didn’t use, and I quote, “mathematical hieroglyphs that academics tend to use so much”, was an entertaining remark I was told at the evening Braai. Besides that, several very interesting points were brought up in the discussion, and I will follow up on one of them in this post.

The most intriguing remark came from Stephan Gruner. He asked me the following question: “Everything you talked about today can be found in abundant resources on Software Engineering. So what’s new in what you presented?” Clearly I did not illustrate the context of my talk well enough that day. Undoubtedly, the three pillars of abstraction and the five principles of software design are not something new. They’re just fancy names that I invented for some of the very basics of software engineering. And yes, already back in the 70s while they were struggling with the waterfall model, these concepts have been in there. Nowadays we’ve got so many software engineering methodologies around, that it becomes impossible to know the details about them all (just to name a few famous ones: XP, RUP, Scrum, Crystal Clear). And that is exactly the point I wanted to make.

In practice —- at least that is what I have experienced —- there are now so many software engineering approaches that they have become a goal in themselves instead of a means for improving software development. That’s why I tried to find foundations, at the meta-process level, that are shared among those different processes. Searching for the foundations that I have found to be useful and thus important for me. I have worked with several different processes (such as the code-as-you-go-with-no-process-at-all method, the heavyweight ESA Software Engineering standard, XP, but also company customized standards), and two things have helped me in all of them. Different levels of reasoning and architectural design; my pillars and princes.

Instead of just working according to process simply for the sake of the process, I think you should always think about why you are following the rules dictated by the process, and more specifically what the goal is that you want to achieve by doing that. And although this sounds just like common sense —- and common sense it is —- I have unfortunately seen this mistake made too often.