Writing Shippable Code (Part Two)


Zoom in/out as required

5. Press the Shutter button

6. View the picture on the internal LCD

7. Switch the camera off


How many touch points are there? The answer is seven. Every step we are doing something and our expectation is that they are all going to do exactly as we ask. It is possible to simplify our process by reducing the number of touch points, making it easier for our end customer to use. Most digital cameras for example, combine the first two steps into one eliminating one touch point. Although, reducing too many touch points can leave you with a system that is not usable.

Touch points do not have to be human interactions. They could also be interactions with other systems. For these, expectations for successful outcomes are more clearly defined as there usually is a published interface detailing precisely what is being expected.


Moments of Truth


Our expectation is that every step in our process is going to do exactly as we ask. But what if it doesn't? What if you cannot get past step one? How do you feel? For our camera example it could be the battery, so we change the battery. What if any of the other steps fail to perform as expected? This is the moment of truth , the moment at which the system could start failing in our eyes. We have asked the system to do something and if it doesn't we are not happy. It only takes one failing moment of truth in any system to leave a bad taste in our mouths. Every other step in the process could work beautifully, but we have been hurt by the one which didn't.

This is where we tend to introduce the majority of our defects in our system by making incorrect assumptions about what we think is a successful customer outcome. Then failing to test our assumptions as part of the way we develop software. We write user stories / use cases with automated unit test but rarely link them together with the successful end customer outcome. If we did and tested our assumptions as we go (like our GPS) then we would be able to deliver with confidence, we would genuinely have shippable code.


Where are we going?


Knowing our final destination when developing a complex software system isn't as cut and dry as it is with a GPS or a route plan. For the latter we know the town or city we are aiming for. Most of the time we even know the precise address. However, by taking a step back and looking at our software system as a whole we can capture the overall successful customer outcome we are aiming at achieving and use this as our clue to our journey's end. We know that once we have provided a system that meets our end customer's expectations through successful outcomes we are completely done. You can capture this high level outcome as your system goal. I recommend that you print this out as large as you possibly can and post it up all over your offices. Let everyone be reminded every minute of the day exactly what it is the end customers are expecting us to do for them.

While this is good for identifying the overall direction we are travelling, how can we ensure that throughout our journey we are not deviating away? To help us, we shall look at how we determine what value to the customer is.

Lean software principles, in fact lean in general, categorises steps within

AgileConnection is a TechWell community.

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