Writing Shippable Code


take to travel along on and our accumulative time spent on the journey so far. No arguments about the route or the time (strangely though 2 hours journey time, but I keep quiet). What's interesting is our behaviour on the journey. My wife tells me to take the next left, which should be in about 3 minutes time and that it's just under 1/2 km away. As I turn left, we both say "that didn't take 3 minutes". We continue doing this throughout the journey until we arrive at our destination on time and have a great day out.

The route plan has set our expectations for each section of the plan. We test these expectations at regular intervals to give us confidence in the plan and to make sure that we are going to reach our destination as expected. Located at the bottom of the route plan is a suggestion that there may be inaccuracies along the way. If we are able to identify them we can provide feedback online when we return home, improving future route plans for other people.

Our instinctive behaviour is to test our assumptions regularly and to make corrective actions when these assumptions are not being met. If the plan isn't clear enough and we keep making mistakes we might abandon the plan and start following our noses in the vain attempt to get there on time. We also like to learn from our mistakes, which leads us to reflect on the journey once we return to see how we can have a better experience next time.

Having the route plan indicate that there might be defects is clear admission from the provider that not only was the plan generated by the information it had at hand, but that there will be allowable defects from time to time. This also changes our behaviour. It suggests to us that defect free enough is ok, and we go along with it. We even feel really good when we find a mistake and can't wait to let the route provider know. We stay loyal to the suggested route just in case we find another one. We are being the good citizen and fixing the world for everyone else.

Developing a complex software system is like going on a journey but with a fundamental difference. We know our start point however our final destination is unclear. We know roughly the direction we should be heading (or at least we think we know). But we constantly make adjustments to our journey as we go.

Traditional software development methodologies tell us to plan, plan, plan, and then when we are done plan some more. By this I mean produce project plans showing how we detail all of our requirements, produce comprehensive design, transfer the design into code, test our system, stabilise our system of defects and then release to our customer. We follow this plan relentlessly until we are either done or realise that we need to re-plan and re-adjust our timescales (the later is the most likely). But it was the detailed journey plan for our day out which was most successful. This goes against the grain for agile software development. Or does it?


The Agile journey


Agile software development teaches us to produce our system by delivering value to the customer through small increments of potentially shippable code. After each iteration we reflect on how we worked and make adjustments to improve (Do, Inspect Adapt). We plan our journey using the product backlog, but we only get to the detail in an iteration for the elements

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.