Slides from “Evolution of Software Architectures”

See here for the slides from the “Much Ado About Agile” presentation, including the one about the Eierlegende Wollmilchsau. 

This was very inspiring conference with great people and a flood of new ideas and knowledge. A big thanks to the volunteer organizers who worked so hard to make it possible. You guys rock.

Presentation for Agile Vancouver: Evolution of Software Architectures over Time

Here’s the abstract of my upcoming presentation at “Much Ado About Agile” on Nov. 3rd. Hope to see you there.

Riding Entropy: Evolution of Software Architectures over Time – Patterns, Smells and Interventions

Software architectures have a tendency to change during the software development lifecycle:

• Requirements not foreseen by the original designers necessitate refactoring.
• Time pressure leads to “shortcuts” which are not necessarily compatible with the original idea.
• The intentions of the original architects are no longer known or have been superseded by changes in the business environment.
• Uneven developer skill sets result in different programming styles in different parts of the application.

More often than not, the kind of changes which affect a system’s architecture are side effects rather than deliberate choices. They are caused less by technical factors and more by the business- and organisational environment in which developers operate.

The session explores examples of directions this evolution can take, with an informal attempt to identify some patterns and antipatterns which may help practitioners to direct the process.

Firewalling Complexity: Eventful Lives Of The Chicken And The Pig

Had a long-ago ALT.NET Canada discussion with Oren about isolating complexity. It came back vividly after yesterday’s conversations at Agile Vancouver’s "Agile Methodology for IIBA" fishbowl.

Much of the initial group discussions were about the role of business analysts in a SCRUM environment and the role of developers when it comes to acquiring business domain knowledge. It felt very difficult to try to delineate responsibilities by hard and fast rules. My understanding of the gist of last night’s comments went something like this:

• If all domain knowledge rests with the BA who hands off use cases to developers who do all things “technical” we are looking at a waterfall scenario with dangerous potential for meaning and purpose getting lost in translation. Continuous feedback and a view of the bigger picture are vital to get the details of the implementation right.
• Without BAs, the bigger picture would be lost because developers will have little time to look beyond the current sprint.
• Without BAs as intermediaries and “repositories of domain knowledge”, developers’ access to product owners and stakeholders would be too limited.

Observation by a panelist when trying to draw the line between more technical BAs and more “businessy” developers: “It depends. Not all BAs and developers are created equal. Not all teams are suitable for all approaches.”

Indeed. Add to this fact that the level of domain- and technical knowledge about a project fluctuates as members move on and new folks join.

As ever, the Engineering Mind turns to fighting entropy by technological means, with a new twist to layering:

Applications with “chickens” and “pigs”:

• “Pig” layers are expert-only, git-yer-hands-off-that-code, for the hard core committed who know the domain and technology inside out. To quote from the loudest movie of 1998: “No touch anything. You’re all cowboys.” With luck, this is also the part of the application which is nailed down hard with lots of automated tests. Examples for pigs are the layering calculations part for a reinsurance workflow application,  route optimization for a dispatch system and similar knowledge-heavy bits and pieces.
• “Chicken” lairs (Layers. I meant layers.) are for new kids on the block, folks in a hurry and people who are pigs in other projects and need to interface with our project without any interest or time for nuts & bolts. Examples for chickens: Updating contact information, reporting, generic functionality where the problem domain is familiar to most of us (new user signup, forgotten password, …).

“Pigs” are accessed via well-defined and documented facades which hide the underlying complexity. They may raise events which can be listened to by any chickens who care so they may extend the system without changing pig code and without the need for in-depth understanding of OO concepts such as when not to use inheritance.

The “What domain knowledge for whom” issue is simplified: “Pig” developers need a lot, “chickens” not so much.  There would even be some rough-and-ready guidance for refactoring: Move legacy systems towards separating chickens from the pigs.

If test suites for pigs exist at a level of granularity where mildly technical BAs can see whether they fit requirements, LAROS can’t be far behind.

TechDays 2009 Impressions: Dialog Refactors Mind

Thank you all who attended the “Refactoring for Fun & Profit” presentation. I had fun preparing it and learned a lot from some very smart people, not all of it about technology.

To me, TechDays was a reminder that nothing in the TwitterFacebookBlogospheroVerse comes close to old-fashioned human contact. It’s as if face-to-face dialog is the ultimate in full-immersion learning by experience. Preparing presentations for the Developer Foundations track was a lot of back-and-forth of ideas, suggestions, banter. Special thanks to Justice, Adam D., Stefan, Adam C.  and Peter – you guys rock! Thanks also to John Bristowe for making the track possible.

There were really good conversations after the sessions and at ALT.NET Vancouver’s Open Space at Mooses’s Down Under on Tuesday.

Dialog as "codeless refactoring”, anyone?  Shape shared understanding well enough in advance of implementing and maybe we’ll re-write a lot less? Nah. Give me a corner with a keyboard and screen. Go away. I’m coding.

Evolving Software Architectures: Riding The Golden Groove

Some observations on Overdesign and Underdesign in software engineering.

How much is enough? What are the consequences of either?

• Underdesign is the familiar software  industry concept where you go ahead with building the car, on the understanding that you can always decide on the number of wheels it needs to have after you are done.
• Overdesign anticipates all possible ways the car could conceivably change in future model years. Considerable effort is spent on getting the number of wheels exactly right. We may lose sales in some of the future model years because of delays caused by implementing the technological equivalent of analysis paralysis.

Because waterfalls are unworkable (not to mention unfashionable),  the pitfalls of either design direction can be felt all along the software development lifecycle:

Just Say No: IT Cost Of Ownership’s Dirty Secret

Maintainable software applications are The Right Thing:

• They take the gut-wrench out fixing bugs and adding features, theoretically keeping us sane.
• In an entropy-sodden world, they are very hard to build.
• Writing code has nothing to do with it. OK. Maybe a little. Perhaps 50%.

There are times when it feels as if deciding what to build is maybe half the picture.

The rest is saying no to building The Wrong Thing .

Building The Right Thing cuts maintenance work because there is no need to change The Wrong Thing. It makes for a decent chance that new features are requested for The Right Reason:

Users LOVE the application and want more.

As opposed to The Wrong Reason:

It doesn’t work right.  This pig is is going to need a lot of make-up.

Let Usability Rule.

Building The Right Thing: “I wanna talk to my usability guy…”

Usability for users:

“Don’t make me think”.  Steve Krug said it best.

Usability for developers:

“There is nothing so useless as doing efficiently that which should not be done at all.” - Peter Drucker

Usability is the difference between building applications which conquer the world (OK -  metaphorically …)  and applications on a backup,  gathering dust on a shelf.

Just came off an assignment which involved a usability assessment for a “90% complete” system.  We identified  some low hanging fruit with potential  for improving the user experience  without excessive re-writes.

Architecture Evolutionary Patterns

Started playing with patterns and antipatterns which might describe the evolution of system architectures over their lifetime .  Hypothetically, one could identify smells which indicate that an application is headed towards one of them.  Potentially, drift towards anti-patterns could be remedied by best-practices mitigation strategies associated with the pattern.

Deliberate Unmaintainability: Burning Bridges To Fight The Cold

Getting a software project done by brute-force coding without putting effort into design and automated tests can work. Maintenance and attempts to add new features might be nightmarish, but version 1 might actually be there when needed:  The client is happy, repeat business ensues. The product gets to market in time, sales are made which would have been lost otherwise.

It’s like burning bridges to fight the cold: You may be warm, but you’d better be sure you aren’t planning on going anywhere later.

Accidental Architecture: Fatal Attraction Of The Hourglass

Inspired by http://news.bbc.co.uk/2/hi/entertainment/4563751.stm,  I was doodling to find a notation to describe evolution of software architectures over time.  A number of database-centric systems I have seen in recent years could be depicted  along the lines of: