Writing Shippable Code (Part Two)

[article]

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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03