Writing Shippable Code (Part Two)


The first part of this article introduced the concept that developing a complex software system was like going on a journey. I contrasted how we plan our journeys through the use of route planning systems against that of an agile journey which is more like using a GPS in our car. I also introduced the idea that we only know when we have reached our journeys end (being completely done) when we have demonstrated that we have fully satisfied the expectations of the customer, our criteria for a successful outcome and that we can use this thinking throughout our project so that each iteration delivers software which can achieve a successful customer outcome.

In this months article I will explain how we express the criteria for a successful outcome in the context of our software system and will uncover a loophole many agile teams overlook. Part three will then conclude with demonstrating how this can be overcome in our code so that we can deliver shippable code. It may help you to read / recap part one as I will continue where that left off.


I don't like GPS


Not everyone likes or gets on with a GPS. This first thing people do after purchasing one is to request a route they have done thousands of times, they could even do it blindfolded if it was legal. It works and suggests roads they would have chosen. We do this to validate whether we will get a successful outcome before we use it anger. But how will the GPS system compare to the old method? Your passenger used to call out the various road changes and junctions as they approached. What role do they now play in your journey? Will they sit back and enjoy the ride? Maybe they start to suggest alternative directions during the journey so that you end up switching it off. Our managers begin to feel redundant like our passengers as they no longer need to chase round asking how we are getting on, instead our count of passing tests v total tests to pass does this automatically for them.

Although test code is short term overhead, longer term it's an essential safety-net ensuring that the journey towards our destination (shippable code) doesn't end up leaving a trail of debris (defects). Having the test code accelerates our productivity by allowing us to deliver more functionality than previously since we have increased knowledge of what is and what is not working. Management have spent many years delivering and testing products the old way, they often see no value in the new and will attempt to steer any agile transformation (especially automated testing) back to their old comfortable way just like our redundant passengers.

The hitchhiker

Agile development has for some time been heralded as the new new way to develop software. The agile manifesto itself encourages a different way of thinking about how we go about delivering code. There are extremists though who in many ways go even further and hitchhike their way through development. Only looking at where they are now without regard to where they need to get to next. They jump on the next iteration to take them a little way in the direction they are heading and continue doing this until they reach their destination. There are often several unknowns to this way of travelling; projected journey time, estimated journey costs and level of completeness throughout the journey. Though for some journeys this means of travelling is quite acceptable.

However, after each iteration, they reflect on where they are, making directional adjustments to ensure they will reach their destination. Sometimes even backtracking when taken down the wrong road. They only design the area of the code they need and only focus on what is currently known adapting this as their knowledge increases. If we coupled this thinking with knowing our criteria for a successful outcome (testing our assumptions as we go) we would have much higher confidence in that we have only produced (code) what was actually needed and that it does meets our customer's expectations. Maybe we need to give our hitchhikers a GPS "At the next interchange, flag down the sliver lorry who will take you 4 miles southbound, depart there and collect


AgileConnection is a TechWell community.

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