Posts filed under ‘Architecture & Design’

“Legacy Code: Using Domain-Driven Design to Carve Out Areas of Sanity” Now On InfoQ


(Presentation from )


February 13, 2013 at 9:37 am 2 comments

What is Software Architecture?

It’s about designing systems to support an initial release on the PowerPoint platform, using  patterns,  boxes and arrows.

No – what is software architecture, the essence of it?

It’s an exercise in user experience design.

The history of computing can be seen as a series of attempts to make building software simpler to understand.

This is because the number of factors we can keep in mind at the same time is limited; The level of detail to which we can understand problems and reason about them is constrained by time and capacity.

If we get overwhelmed by complexity we get bugs and it takes longer to deliver the system. We fail to meet the objective: Most of us produce marketable features for sale, directly or indirectly. Simplicity speeds us up. Complexity slows us down. Slow delivery means less to sell and ultimately less money to pay us with.

The user experience of building, deploying and maintaining marketable features must be simple. This is the goal of software architecture.

September 8, 2012 at 7:31 am Leave a comment

If Cars Were Software

Coupling & Cohesion: “We installed your new radio. The tuner is in the trunk, we put the amplifier in the glove compartment and integrated the CD player with the carburetor.”

Single Responsibility: “Yes, that’s by design. The power windows go up and down as you press the accelerator.”

Open-Closed Principle: “To install your ski rack, let us begin by rebuilding the roof.”

Liskov Substitution: “It looks like a timing belt but behaves like a seat belt.”

Interface Segregation: “The lever to the right of the wheel indicates, switches wipers on or off, opens the trunk, controls A/C temperature and now let me show you  how you use it to input destination addresses for the GPS …”

Dependency Inversion: “I’m sorry – we can’t replace the battery. The headlights will only work with this particular brand.”

Consistent levels of abstraction: “By rotating, the pinion engages the teeth on the rack, thus translating rotational motion into linear motion which results in changing the angle of the front wheels relative to the back wheels. This is how you go left or right by turning the steering wheel.”

November 9, 2011 at 7:44 am Leave a comment

The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It

Gave this presentation at this year’s Agile Vancouver conference.   Thank you everybody who attended – much food for thought and ideas in the discussions afterwards. The slides can be found at .

If Agile works, why isn’t everyone doing it? Or, as Agile has become fashionable of late, why all the lip service without the expected amount of real change? This talk makes the argument that it comes down to trust and presents tools and examples for building and keeping trust. The focus is on how to project plan and design applications in a way which, wherever possible, avoids putting stakeholders into situations which require trust in the first place.

In a nutshell:

  • Own your stack. If possible, use one co-located team per bounded context and architect systems in a way which allows developers to easily write end-to-end tests and do releases.
  • Make sure you and your stakeholders have a shared definition of what success looks like. Are you measuring the same things?  For example:  “Diligence in planning” vs. “Adaptability when responding to new knowledge”:  In light of the former, finding something unplanned-for is failure. For the latter, it’s learning and success is measured by how well the new knowledge is assimilated.

November 7, 2011 at 7:24 am Leave a comment

LiskovCheck: Semi-Automatic Liskov Substitution Principle Adherence Check

LiskovCheck.exe is a command line utility which scans .NET assemblies for inheritance relationships and lists them in English sentences such as (from nunit.framework.dll):

  • “It looks like a LessThanConstraint and behaves like a ComparisonConstraint.”
  • “It looks like an AssertionHelper and behaves like a ConstraintFactory”.

The first sentence sounds about right, but the second one raises eyebrows: One could swap things and say “It looks like a ComparisonConstraint and behaves like a LessThanConstraint.”  However, “It looks like a ConstraintFactory and behaves like an AssertionHelper” makes less sense. (Disclaimer: I haven’t looked at the nunit source – no idea what this is.)

From LiskovCheck’s SpecFlow acceptance tests:

Feature: Semi-automatic check for adherence to the Liskov Substitution Principle.

Definition of the Liskov Substitution Principle:

“Liskov substitution principle (LSP) is a particular definition of a
subtyping relation, called (strong) behavioral subtyping.”

…also known as:

“If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction.”
(from )

Scenario: A subtype is more likely to adhere to the Liskov Substitution Principle.

Given a DLL named Zoo.dll with a “Duck” class which inherits from “Animal”
When I run “liskovcheck Zoo.dll”
Then the words “It looks like a Duck and behaves like an Animal” should be on the screen.

Scenario: A subtype is less likely to adhere to the Liskov Substitution Principle

Given a DLL named Zoo.dll with a “MerganserDuck” class which inherits from “TransistorRadio”
When I run liskovcheck.exe with the argument ‘Zoo.dll'”
Then the words “It looks like a MerganserDuck and behaves like a TransistorRadio” should be on the screen.

The project is on GitHub at

To try it out:

  • On click “Downloads” and download
  • Unzip the file.
  • Open a command window in the LiskovCheck-0.0.1 folder and run (e.g.) ‘liskovcheck Ninject.dll’.
  • You may need to “Unblock” a downloaded .dll file  first, by right clicking it, going to “Properties” and selecting “Unblock”.

I wrote LiskovCheck as an excuse to play around with Ninject, SpecFlow and OpenWrap.

For more information, see



February 13, 2011 at 9:50 pm Leave a comment

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.

November 6, 2009 at 9:43 am Leave a comment

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.

October 7, 2009 at 2:48 pm Leave a comment

Older Posts