Slacklining & Software Development

Updated: Sep 29, 2019

Take a look at this guy on the slackline:

Will you advise him to:

  • Walk the rope without a harness?

  • Cross the rope in sprints?

  • Fix mistakes at the end?

  • Rebalance every 10 feet?

  • Take this challenge without practice?

Obviously none of these, right?! Crossing without a harness would probably give you a heart

attack, and waiting to fix your mistakes until the end or trying to walk across without practice

will just leave you at the bottom of a ravine. So all of these options sound less than totally

pleasant. You also can’t rebalance every 10 feet or you run the risk of falling. Crossing in

sprints entails you may be speeding up or stopping to evaluate where you are in the mission. The fastest way to get across that tight rope is small, balanced steps. This is a clear example where doing it the right way the first time is both fastest and with the highest likelihood of success, and in this case, also saves your life.


Nice video, but how exactly small steps make you go faster?

I Agree, small steps in real life don’t usually make you go faster. But small steps do make you go safer! It is the safety that we build into our everyday activities that make us go faster. Wherever both the probability and the cost of mistakes are high, the only way to make fast progress is to make it safe. In this example, the effort and time spent climbing back on the rope and rebalancing after each fall will surely consume more time and effort than the alternative of simply taking the smallest steps possible and maintaining your balance.


And what does slacklining have to do with software?

I’m glad you asked. Clearly, this is just an analogy. As we all know, computer programs are both complex and fragile and we humans are error-prone. With software, like with walking on a rope, the probability of making a mistake is pretty high and the cost of such an error may get high as well. The solution in a software world is to maintain valid, deployable code at any moment. In fact, I argue that the cost of building software in any other way has negative financial and people impacts.


What is a small software step?


In software, we create value by making small functional increments called Feedback Cycles. Each such feedback cycle is designed to Safely generate functionality driving Customer Value.

There is only one rule to follow regarding feedback cycles:


The smaller the better!




Feeback-able != Shippable

Quality only exists where there's feedback. Although we deliver/ship value in shippable increments we build quality in feedback-able increments. Each potentially shippable increment is made of many, much smaller, feedback-able increments.


In order to build quality software, we should shift the focus from cycles of shippable increments to cycles of feedback-able increments. When compared to shippable increments, Feedback-able increments can be very short, just a few hours of work. The goal of a feedback-able increment of work is to have a snippet of functionality coded in an optimal way. As illustrated above, we make no distinction between customer value and safety. Each feedback cycle combines well defined automated acceptance cafeteria with rigorous refactoring and clean coding. Almost always, this type of development can be completed in less than a day.


I realize this implies we must rethink the prod-dev interaction. Instead of intervals based interaction we should prefer ongoing involvement. Back to our tight rope, our harness is knowing that the functionality is working. When we refactor, we never break the code, and therefore we can deploy at any time. Instead of sprints that may cause stops, starts and speed changes, we constantly prioritize the next most important thing and follow the same process: get functionality out there, refactor to optimize, deploy our small increment. It’s the safest way to write software, and as it results in the fewest errors, it’s also the fastest.


Conclusions

Software development involves a high probability of making mistakes. Just like slacklining, we can mediate that risk by building the quality into the ongoing activities and not leaving it until the end. We can do that by breaking the large shippable increments into much smaller quality steps called feedback cycles.


Expect more from me as I delve into how we optimally write code to move as safe and as fast as possible to maximize financial benefits for our business.



Special thanks to Dustin O'Brien for his excellent constructive feedback.

31 views0 comments

Recent Posts

See All