SPA Conference session: Last Responsible Moment or Big Ball of Mud?
|One-line description:||How to give your developers as much design freedom as possible while making sure you don't end up with the proverbial Big Ball of Mud|
|Session format:||Workshop 150 minutes [read about the different session types]|
|Abstract:||In a 2000 paper for the Lean Construction Institute, Glenn Ballard and Todd Zabelle introduced the concept of "last responsible moment" as a foundational principle of lean project management and set based design.|
They define it as "the point in time at which there is no longer sufficient lead time to realize [an] alternative [design]." Mary and Tom Poppendieck define it as "the moment at which failing to make a decision eliminates an important alternative."
In other words, once you have passed the last responsible moment to make a decision, you can't turn back. On the other hand, before you get there, you can still change your mind if you discover there is actually a better way.
(Martin Fowler also considers this idea in his (somewhat tongue-in-cheek) IEEE article from 2003, "Who Needs an Architect?" He makes the point that that irreversibility of decisions is one of the prime drivers of system complexity, and discusses a technique for deferring schema changes he calls "Evolutionary Database Design."
Some design decisions clearly can be deferred, such as those which affect your system's look-and-feel, while others have to be made early on - for example, your choice of implementation language. However the majority of design decisions fall somewhere on the scale between "Must Decide Up Front" and "Can Leave Till Quite Late."
In this workshop you will attempt to apply the principles of Last Responsible Moment to some real-world design decisions. We will work in groups to identify interesting design decisions from current and past projects and map each decision to the right point on the scale. For the "early-on decisions," we will consider whether there are any practical ways we can defer these decisions until later. For those decisions which fall nearer the other end of the time scale, we will look at the risks of leaving these decisions late, and practical ways to mitigate those risks.
|Audience background:||Developers, designers and architects|
|Benefits of participating:||You will come out of the session with a much better understanding of how to apply this technique in practice, and some design patterns / architectural styles which you can use in your projects|
|Materials provided:||- Session slides (including a couple of worked examples to explain what's going on)|
- Write-up of conclusions on the SPA Wiki
|Process:||- form into small groups|
- share interesting design decisions from current and past projects you have worked on
- categorise each of these on the spectrum from "Must Decide Up Front" and "Can Leave Till Quite Late" (with rationale)
- for the early-on decisions, each group will discuss whether there are ways we can architect and design systems to move them further out
- the groups will then share their conclusions with the workshop
- for the middle- and late decisions, each group will identify any risks and develop strategies to mitigate them
- each group will then share their conclusions with the workshop
- we will finish with a brief round-up and lessons learned
|Detailed timetable:||00:00 - 00:30 Introduction, background and examples|
00:30 - 00:40 Form into groups
00:40 - 01:15 Exercise 1:
Share interesting design decisions from current and past projects and categorise
each on the spectrum from "Must Decide Up Front" and "Can Leave Till Quite Late"
01:15 - 01:30 Break
01:30 - 02:00 Exercise 2:
For the "early-on" decisions, discuss whether there are ways we can architect
and design systems to move them further out
02:00 - 02:20 Groups present their conclusions
02:20 - 02:30 Wrap up and lessons learned
write-up of materials produced on the conference Wiki
|History:||I have not presented this session before|
|1. Nick Rozanski
Barclays Investment Bank
|2. Eoin Woods
|3. Chris Cooper-Bland
Endava (UK) Ltd