The Agile Team Room

During a recent training course, we discussed the agile team room, especially the whiteboard space for modelling. Fortunately, Mike Cohn just published a blog, listing the essential features for The Ideal Agile Workspace:

• Big Visible Charts
• Additional feedback devices
• Everyone on your team
• The sprint backlog
• The product backlog
• At least one big white board
• Someplace quiet and private
• Food and drink, and finally
• A window
  

The comments link to several implementations of this list. For instance, one of the comments link to a tour through the msdn Patterns and Practices Lab and a peek inside the p&p Team Room. Of course, these are quite advanced implementations of Mike's list, but show how important these companies find the physical environment.

DCI, or restoring order to OO

Object orientation (OO) is often contrasted with structured programming (SP). OO has many advantages when it comes to managing complexity, but it clearly lacks in exposing clairly what the code is actually achieving. SP on the other hand has many defeciencies when it comes to separation of concerns and maintainability, but at least it is normally possible to follow the execution sequence in the code.

In my OO training courses, I frequently warn the attendees, saying that OO may solve the problem of complexity and changeability, but requires another level of competence to maintain clarity and overall understandability. A lack of this competence may produce a spaghetti code that is an order of magnitude worse that the traditional, structured spaghetti code. Please be warned!

Enters Professor Trygve Reenskaug, the principal inventor of the MVC paradigm, with a new DCI paradigm, supported by Jim Coplien. As I understand it, DCI is complementing OO and MVC, supplying the overall interaction scheme, showing how the individual objects, based on their roles, collaborate to deliver business value: It supplies a role based expression of the communication logic, like in sequence or communication diagrams.

I have to look closer into the material, for instance how DCI expresses the communication scheme better than e.g. communication digrams, but it does look interesting.

… but please do repeat me

Do you have to choose duplication, paralysis, or chaos?

Johannes Brodwall wrote a blog with this title on a subject that has interested me for a long time: How to avoid chaos and support stability in face of a constantly changing interface (my rephrasing). He sketches three different approaches:

1. Duplicate code, so that change at one place does not affect code somewhere else, but at the cost of duplicated changes of common logic
   
2. Share code, to avoid duplicated changes of common logic, but at the cost of requiring change in all the clients when the logic of any of the suppliers changes
3. Do not allow changes, to avoid both of the inconveniences above, but at the cost of conserving unsatisfactory solutions

I tend to think that the solution will change over time.

• Initial code is unstable and has only a few clients. Apply approach 2.
  
• As code matures and stabilizes, fix its contract (precondition and postcondition). Apply rule 3 and the open/closed principle.
  
• A subsequent change may of may not break the contract.

1. If it does not (weaker precondtion, stronger postcondition), there is nothing to worry about - clients are not affected by the change. All tests will pass unchanged.
   
2. If it does, apply rule 1 and define a new function for the new contract, possibly making the old definition deprecated to leave a transision time for the clients.