Evolving Software Architectures: Riding The Golden Groove

July 18, 2009 at 2:54 pm Leave a comment

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:


Software systems evolve over time as features are added and maintenance is done.  A scenario for what one might call the “Flexibility-Side Effects Trap” would be where an initial prototype is built quickly without much thought for longer term consequences of design- and implementation decisions. If everybody is really happy with the prototype, one frequent situation is that stakeholders shy away from the initially higher cost of scrapping the prototype and re-engineering from scratch. Therefore, the prototype is turned into the live system. There are circumstances where this makes sense, but the flexibility which made the back-of-an-envelope prototype a success can have longer term (potentially very costly) perils:  Coupling and cohesion issues are very common here. Both are more likely if developers are not having enough opportunity to consider the 10,000 ft. level (… the design/architecture…) of what they are building:

  • A typical “smell” for a tightly coupled system: Developers are reluctant to make changes because doing so may break other parts of the application.
  • A typical indicator for cohesion issues: Ramp-up times for developers are long because it is hard to understand what the code does.

A lot of the shops where I have encountered the “flexibility-side effects trap” were start-ups and highly entrepreneurial companies where an excess of can-do attitude seems to create a bias towards going down that route.

The “Infrastructure Overhead Trap” would be at the opposite end of the spectrum:  I’ve seen this in environments with ample resources (often larger organizations) who place a premium on re-use and thorough planning.

Typical warning signs are:

  • Developer-driven development. The business side of the house is underrepresented and/or overawed. Engineers rule the roost and can make design decision based purely on technical considerations, without sufficient emphasis on getting buy-in for downstream consequences for maintenance- and opportunity cost.
  • Ramp-up times for developers are long because it takes a lot of talent to understand “our framework”, “our standards” and “our way of doing things”.
  • Frameworkitis and (it’s evil twin) abstrationitis. A tendency to derive a general solution from what was originally the objective of catering to a specific set of business needs.  One  typical consequence is a negative effect on usability of the system because the team focuses energy on refining the plumbing at the expense of working on the user experience.

A system in the “infrastructure overhead” trap seems to have a tendency to devolve towards “flexibility-side effects”:  Coupling goes up and cohesion decreases as developers with deadlines have to be productive before they gain a thorough understanding of the architecture and as they try to sidestep unwieldy infrastructure code.

Perversely, although the modes of thinking and operating which lead into either trap are very different, the consequences of getting trapped are the same:

  • The rate at which new features and fixes can be implemented goes down.
  • The cost of doing so goes up.

The likelihood of falling into either trap increases with the complexity of the problem the application is trying to address.

Over the lifetime of a system, the task of the developers/architects/PMs/product managers/team leads comes down to keep the application in some kind of “Golden Groove“:

Enough design to keep things maintainable, but no more.

… which, as statements go, is infuriatingly vague. Unfortunately,  if one limits oneself solely to the mechanics of designing software, there appears to be no right answer:

Knowing what constitutes overdesign and underdesign means understanding the strategic and tactical business objectives the application is intended to serve.


Entry filed under: Agile Project Management, Architecture & Design.

Just Say No: IT Cost Of Ownership’s Dirty Secret TechDays 2009 Impressions: Dialog Refactors Mind

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: