Abstraction is evil

Been a while but attended a very interested seminar last week featuring Jim Coplien (author of the book “Lean Architecture: for Agile Software Development”, among other things) titled “Modern Domain Analysis for Agile System Development”.

I’m not going to try to recap exactly everything Jim said, you’d be better served to listen to him the next time he speak at a venue close to you, but I will dish out some snippets. I don't necessarily agree to everything Jim said but he made some really good points and made me think and reflect which is what I want out of a seminar. As he pointed out this topic is much easier if you are building a web-based application than if you are working with embedded systems, but hey the world is complex. Tough luck.

 

• Abstraction is evil but compression is good. In Jim’s view all abstraction makes information disappear and we can’t afford to loose information.
• Architecture is the essence of structure, i.e. the form.
• Agile architecture is about making the hard decisions early to make the easy decisions easier later. To defer decisions to “the latest responsible moment” is stupid and simply wrong.
• Agile architecture should provide a stable ground, not necessarily a static ground. It’s about knowing what changes we can ignore.
• Software architects that don’t write code aren’t software architects. Everyone that writes code is part architect. The whole team should be included doing the architecture; the tester, domain experts, system engineers and programmers.
• A good architecture should reduce rework and inconsistency.
• It’s not about no documentation but the documentation should be to the point, only include what matters. The rest of the architecture should be communicated through the code, e.g. abstract base classes.
• Architecture follows the organization (Conway’s law) and the social connections in the organization (rather than the org. chart, and organization follows location, market etc). Other influences to the architecture is the end-user’s mental model, the shear layers with regards to what the system does and what the system is, and finally the domains as long-term stable concepts.
• Partition your system to domains using intuition and history. Analyze your domains, analyze commonality. Find your parameters of variation. Use patterns but beware GOF isn’t patterns.
• DSLs fail.
• Scrum is very good for systems with end-user interaction and GUI, Scrum is very hard for embedded systems…. basically you aren’t doing Scrum.
• An incremental approach to architecture leads to poor structure in the long term, you should do it first and then change it when needed.
• Agile only focus on the revenue but forgets the cost, architecture is a means to reduce cost.  
• Scrum is waterfall but that doesn't mean it is bad.
• You work best with “Architecture” influenced by both Scrum and Lean.
• Scrum is not Lean.

Last but not least. Jim talked around the picture below from an organizational stand point. The picture shows a map of the world from a New Yorkers point of view:

(high-res can be found here)