Emergent Design [Overview]

30 Second Overview.

This technique says that ‘As our requirements are implemented so our underlying design will emerge’ although it is likely that we will have made some over arching decisions such as the client application will be Silverlight we will use RIA services and so on.

In simple terms the design decisions are delayed until we are driven to make them by following our Tests and the artefacts produced by those tests. So there is no upfront design phase and no need for a architect or technical lead as all members of the team are equally empowered and responsible for architectural decisions as they get to the point a decision can no longer be delayed.

Emergent Design says also that all developers in the team are equally empowered and there is no need for a tech lead or over arching solution architect / design authority although you may still need a gate keeper for the domain / domain architect to enforce company wide design options and integration between systems.

Using this principal, communication is imperative across the team , headphones should not be warn in this type of environment information saturation via Osmosis is beneficial as is courage to speak if you don’t agree with something you over hear.

It is also a classic aspect of this type of team that documentation will live in card task lists and although at a seconds notice any team member will be able to draw for you on a white board the solution architecture no architecture diagrams will be produced and generally Visio is a dirty word as each member would expect his colleagues to be able to run a white board session to explain the current architecture therefore making diagrams a outdated slow moving asset that has no place in a emergent environment.

Some of the advantages

  • Fast iterative cycles
  • Flexibility within the architecture to change as the requirement dictates ( flock of swallows principal )
  • Spread of architecture knowledge across the team
  • High quality development , is achieved by architectural chooses under continual review by all developers
  • Highly empowered and motivated team
  • Distributed code and architecture ownership
  • Encourages small checkins and atomic coding practises
  • Highlights weaknesses in the team quickly and encourages individual and team level skill patching
  • Iteration 0 /1 is a productive iteration rather than spending it debating architecture
  • With this style of team everything is immediate you see it , you deal with it very little technical debt is built up as the team will feel uncomfortable with passing by a architectural issue and not solving it immediately, this could probably belong in both challenges and advantages though i see it as the latter speaking from a personal stand point.
  • This method tends to lead to a lot of code reuse and due tot he high rate of refactor that is performed with this method the code tends to be of a very high quality with very little fat and subsequent lower maintenance foot print.
  • Because the code is under continual review by the whole team plus the reliance on B/TDD techniques the bug count at point of release is normally very very low.

Some of the challenges

  • Recruitment becomes very difficult as all the people on the team must pass a minimum bar there is no room for juniors on teams practising this principal, or passengers. ( Principal the team is in this case as strong as its weakest member and as fast as its slowest pair )
  • High code churn as the architectural changes are implemented on the fly across the whole solution not just the focus of that particular card , a architectural refactoring must be cross cutting across preceding code as well as the current card scope.
  • Team must communicate verbally , its imperative that the person proposing an architectural change communicates that change to the rest of the team and they respond in a speedy and honest fashion – fast white board sessions are ideal for this ( hint: time box), there is no place to hide in this sort of team.
  • Velocity can become uneven as people make large refactors, reducing there perceived productivity.
  • This technique does not work well in distributed teams, with out implementing a lot of overhead.
  • It is imperative that there is a understanding of you touched it you own it , in other words just because you didn’t write it , doesn’t mean you can see something you disagree with and pass it by and mentally think ‘ oh well its not my code’.
  • If used with teams that lack maturity or teams that have an element within them that has not brought into this technique , this technique can cause a lot of animosity.
  • It is imperative that this technique is practised with full test coverage , a solid CI (Continuous Integration) it is generally a rule with teams that practise this approach that the code base is constantly deliverable, demoable and a candidate for shipping should it be required, any high risk development is done in a branch and then integrated and generally is spik’ed out first.
  • This technique works best in self organising teams and works badly in command and control style structures.
Advertisements