What Does 'Good' Look Like?
I think that we have a problem in the software development industry. A significant proportion, if not the majority of practitioners have never seen, let alone worked on, an efficient project. This is a scary thought! If people don't know what good looks like, how can we expect them to do well? Software development is a difficult thing. Software is almost uniquely complex and fragile. I can write this blog post and mis-spel all kund of werds and you will still know what I mean. A similar mistake in my code will lead to, at best, code that won't run at all, at worst code that sends the nuclear reactor into overload, crashes the flight control system or loses my company money. Our industry has spent decades working in inefficient ways. Data collected on project success seems to bear this out. Even the more optimistic data suggests that only around 50% of projects that employ traditional approaches to development are successful. (Source: "Scott Ambler, Dr. Dobbs Journal, Feb 2014") Actually Mr Ambler's data suggests that projects that follow an 'Ad-Hoc' approach are 50% successful while projects that follow a "Traditional process" are only 49% successful. So making your process up on the spot is a better strategy than traditional "rigorous" development approaches! (The sample-set is probably too small to really state this with conviction, but it made me laugh when I read it so I thought that I would pass it on.) It is time for a re-think. Many leading edge organizations, in all sorts of market sectors, are adopting a different approach and finding success. These new approaches are rooted in agile development and more specifically in Continuous Delivery. There is growing data that shows that not only are projects that employ Continuous Delivery more efficient at delivering value, but that organizations that embrace these techniques make more money. I think that this is true for some pretty fundamental reasons. Continuous Delivery is aimed at shortening the loop between idea and seeing how well that idea works once it is in the hands of users. This is what business has always wanted from software development, a quick efficient means of getting ideas into the field. This is important because at the business level it allows the organization to become experimental. Instead of assuming what the customers will need in a year or two, we get to value early. There is a great deal of cross-over between ideas like Continuous Delivery, Lean manufacturing and Lean product development. We want to aim to get a minimum viable product into the hands of our users. This is important because we, all of us, are not very good at guessing nor at predicting the future. Because we are not good at guessing, we want to find a way to evaluate our guesses and reflect on what we learn. Because we are not good at predicting the future we want to minimize the period over which we extrapolate. We work at our best when we make short-lived guesses, try them out and build on what we have found to work. This should sound familiar, what I am describing here is the Scientific Method. We want to establish feedback loops, enable experimentation and reflect on what we learn. We want to retain a skeptical mind, don't assume that we know the answer, and we want to find a way to make our guesses falsifiable. The Scientific Method is the most successful invention of humankind. It is by far our best technique for solving hard problems. Continuous Delivery is a more scientific approach to software development. We divide our work into small chunks and work in a way that, as far as our ingenuity will allow, enables us to verify our assumptions. CD allows the business to become experimental. It shortens the gap, the cycle-time, between having an idea and placing it in the hands of our users so that we can test its validity. This is where the real value lies and our focus and drive to improve should always be targeted on this outcome. The businesses that pay for the software that we create have been telling us, for decades, that what we have been doing is not working for them. Most businesses have an adversarial relationship with software development. That isn't all our fault, but neither are we blameless. One thing is certain, we won't get better by doing the same things. So if your business is making demands that your development organization can't meet, start exploring other approaches. Achieving Continuous Delivery is not simple. In part it is difficult because most of us have learned bad habits. Through careers working in sub-optimal projects we have come to believe that the dogma of traditional development process is the "right way to do things". We need to be skeptical of our assumptions, we need to test our ideas, we need to never assume that we will run our projects this way because "that is how we always do it". I think that if we are genuinely focussed on delivering business value as quickly and efficiently as possible, it is hard to argue against trying new things. We must be experimental to see what works. The business too must drop some of its bad habits and become more experimental. We need to find the minimum viable product for each of our ideas. To evaluate them as quickly and cheaply as possible. This is not rocket science, though perhaps it is a close sibling ;-) Follow Dave on Twitter: @davefarley77 View Dave's Blog: http://www.davefarley.net