At certain stages of during your life as a software architect's life, you encounter so many new things that it becomes overwhelming. At these times, you would be more than happy to put on a bear skin, and move into a cave. Preferably without 'the wheel' and 'fire', to avoid falling back into old habits. To be honest, sometimes I actually enjoy this 'leaving the new behind and going back into history'.
What I often notice when talking to people in industry, but also when our government discuss issues like our ongoing traffic congestion, is that only very few people try to see their challenges as part of something bigger. Each challenge, or problem as they are often called, is regarded by itself, even though they are part of a bigger system - be it a machine, a piece of software or the concept of rush hour.
Looking back 10 years, at the time I worked in Philips Research, that surprises me. Back then, the notion of 'systems-of-systems' (every system consists of set of smaller, cooperating systems) looked like something that would really catch on. Then-guru on the subject, Mark Maier, defined a number of criteria to which such a system-of-systems should adhere. Each of the composing systems should be operationally independend and managerially independent - i.e. it should operate, and be developed and maintained independently. On top of that, the complete system-of-systems should develop in an evolutionary way, and show emergent behavior - go beyond the behavior of the individual subsystems. No doubt we'll find such systems nowadays, in fact, I identified a few with some PDEng in Software Design students last week. However, there are but a few - except maybe in the US Defense Industry, where the concept seems to a have been adopted quite well.
A similar reasoning applies to systems thinking, a concept discussed in many books, lectures and projects in books by Peter Senge, Eliyah Goldratt and many others. Roughly, systems thinking works from the notion that everything is connected (like systems-of-systems!), and that the cause of each problem is rarely the nearest link in the chain. Based on this, interesting discoveries were made in areas like economy and logistics over the past few decades. In systems industry unfortunately, we still find ourselves dealing mainly with the symptoms rather than the root cause of our challenges.
In between reading and pondering over these things from my past, I also read a summary (and a lot of tweets) of a presentation by Barbara Liskov, at OOPSLA 2009. She's a software engineering specialist, who recently received the ACM Turing Award for her contribution to software engineering as a discipline. In her presentation she stressed amongst others that 'young software engineers know to little about the history of software engineering'. That got me interested, after all history and bear skin mix very well. As examples, she mentioned that 'extensible programming languages are a nightmare' and 'it's more important for code to be easy to read than to write'. I tend to agree with here, in a way. After all, some of our modern 'extensible' programming languages haven't fully achieved their goal. Python for example didn't go through a complete rewrite without a reason, and we'll still have to wait and see what Lua and Ruby will go through in the next few years.
Also, from a maintenance perspective, I can only agree that readable code is very useful. After all, many companies and developers still document their software only poorly and that legacy is carried for years. On the other hand though, easy to write code will improve our productivity, and DSLs and code generation were introduced for a reason (don't they serve both sides?).
All in all, I get the feeling Barbara addressed things quite well, taking into account pro's and con's, based on over 30 years of software engineering experience. New developments are useful and necessary, but we seem to be continuously returning to old habits and old mistakes and ineffective solutions, because we fail to see the past and the bigger picture. With that, she addresses a pitfall which seems to already have swallowed that other giant from the past, Grady Booch. He stated in an interview, around the same time as Liskov's presentation, that ' we should go back to the roots of UML' and that 'the main artifact is raw, naked code, everything else is secondary to that'. Just now, at the time model driven development and code start showing their real advantages...
After reading Barbara's story, and Grady's interview, I shrugged off my bear skin once again, and sat down by the fire to read an article on the latest developments in IT and software engineering. Sometimes it's good to look back, but let's start trying to pick up the right new things and hold on to them, rather than giving in to our old fear of change.
[to be published in Dutch in Bits & Chips magazine #18, 2009]