Interface first development and Mocking [Overview]

30 Second Overview

Although this technique really falls within the ‘Emergent Design Umbrella’ it would be remiss of me to not to write a quick overview.

This technique introduces two visualizing concepts to the reader:

  • Coding shallow and wide
  • Implementing deep

Ok so what does all that mean , well in simple terms your aim is to code in multiple passes the first pass you implement the behaviour to satisfy your BDD test by hammering out interfaces and you mock everything do not even allow your mind to wonder to the how do i implement X instead just trust that it will become clear as you proceed.

So in the first pass everything or almost everything is a mock and you will be passing values into one mock and pulling them out of another when you stand back and look at that first pass your first reaction will be that’s pointless, mine certainly was the first time i did.

But if you have now coded shallow.

So next start pushing down towards your deep end point perhaps a mocked repository or some such. So next you might make the Adapter concrete and start to implement a service call perhaps via a channel factory. This will of course lead you to implement the service and because we are best practise team you will be injecting into it via its constructor (DI/IOC) its repository which is still mocked.

So you will be driven in the setup code for your test to hammer out the host and perhaps a Unity (or other DI) service behaviour/host/ binding then you will rerun your test ad you will find that now you have coded deep and implemented the behaviour you prototyped in the first pass. So you move on till you get to the your test end point which might be a in memory database or a mocked repository or something else that suits your domain pattern.

The golden rule with this is ‘ Implement only when driven there, delay implementation of an object as long as practical and sensible’.

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.

BDD [Overview]

30 Second Overview.

One of the main disciplines the teams i work with is Behaviour Driven Development this approach to software design was introduced to the community by Dan North a number of years ago and although it has not gained the following its sister discipline of TDD (Test Driven Development) has gained, those that practise BDD tend to produce a far more accurate representation of the Business Analysts vision and thus the customers dream.

Within a BDD Test / Spec we aim to use common English language sentence to describe the functionality that we need to be produced our scope is a business stripe though the technical layers rather than a method or object as in TDD.

Brief Presentation on some of the BDD frameworks in common use: https://www.box.net/shared/2tfmm2ubgo

Some of the advantages

  • Requirements are the driving force behind the tests , which in turn drives the code
  • The technique trims away code waste
  • The technique creates a pit of success for the developer
  • The technique encourages other good practises such as contract first development and emergent design principals.
  • Helps developers understand what ‘Done’ really is for the story

Some of the challenges

  • The technique requires a lot of discipline across the team
  • The technique takes away some of the freedom from developers
  • The technique doesn’t work in environments where P & P , SOLID and best practises are not followed.
  • The technique required a ‘BA’ role to be performed within the team
  • The BA must be very explicit in there requirements and child acceptance criteria, also it is helpful if they supply wireframes and such like to augment the requirement statements