I attended an evening session, “In the brain of Simon Brown: How much up front design is just enough?”, at Skills Matter on Tuesday, 24th April.

As part of the session we explored the themes of “not enough” and “too much” design in an attempt to work out what “just enough” design would be.

We began by individually writing post-it notes about three or four extreme situations where we’ve either personally experienced or could foresee  ”not enough” design (e.g. “the team doesn’t know what it is doing”) taking place and at the other end of the spectrum when “too much” design (e.g. “delivering a 400 page document and not coding”) has been undertaken.

We then assembled in groups of around five people, though there were seven in mine, and identified the common themes (affinities) in our individual notes and grouped those on the same theme together in rows under the headings of “not enough” and “too much” design.  

Once we had the two stacks of extremes on the same theme in a row we thought about what would be an appropriate note to put between them, in a column headed “just enough”, which would represent the mid-point between the two extremes.  

Finally, when we were satisfied with the way the notes had converged each group transported their notes to the central whiteboard.  Again, repeating the same process that took place in the group but on a larger scale and either creating a new row on the board or stacking the row on top of an existing row with the same theme. 

At the end of the night I took a random row of notes from the central whiteboard home with me and volunteered to post them up on the web.

What did the notes say?

The notes seem to be a mix of general situations that we’ve all experienced and some rather specific situations that someone needed to get off their chest.

Not enough:

• “No infrastructure identified”
• “No idea of topology”
• “When responsibility is duplicated across the codebase”
• “Not taking time to understand existing systems and integration points (high risk, may not be DRY”)
• “Components don’t fit together”
• “Not allowing others to see you are re-inventing the wheel”
• “Dependency [PR: can’t make it out, any ideas?] between modules”
• “Last minute technology choice”
• “When you have 3 webservice stacks in the same JVM”
• “Each part of the system is designed differently from the next. No common patterns are followed making the code difficult to communicate”
• “Constraints not known”
• “No idea of responsibility boundaries”

Just enough:

• “Tech/Arch constraints/constants and why”
• “Tech vision”
• “Just enough investigation (spikes)”

Too much:

• “No creativity”
• “Too much everyone’s burnt out before any coding starts”

The notes that I collected seem to point to having enough design to get started, for the team to have a shared vision and understanding of the structure so that the major pieces are identified and aren’t repeated (keeping it DRY).  

There’s a need to ensure that team members know, and this sounds obvious as I’m typing it out, what others are doing to avoid “reinventing the wheel” as one note suggests and so the team pulls in the same direction.  

Moreover, all this needs to take place without being overly prescriptive and stifling creativity.  

I fear that’s all easier said that done. 

So, how much is enough?

In short, I still don’t know.

The answer to this question is dependent on the particular situation you find yourself in. It is certainly going to be influenced by, among many other things, the culture of the company you work in, the personality and skills of the developers in the team and almost certainly the internal corporate politics from which arbitrary constraints on projects are placed.

What’s out there?

There is a need, and I have been searching which is why I attended the session, for a balance between the emergent (and at the extreme, “hope it works out” design) that Agile can bring and the other extreme of “big requirements up front” (sometimes leading to “analysis paralysis”) that Waterfall can deliver.  

DSDM Atern was mentioned in the presentation and is something that I’ll certainly be reading up on.  I am also going to buy a copy of Simon Brown’s book, “Software Architecture for Developers” on Leanpub.

I think, although the session sparked off a lot of ideas (which we continued to discuss in the pub afterwards), the search for an answer to the question, “How much up front design is just enough?”, continues…

Other write-ups of this event

tapmantwo - “Just Enough” upfront design

Source Notes