One of my favorite books, in the field of software development, opens with:
The most important problem that we face as software professionals is this: If somebody thinks of a good idea, how do we deliver it to users as quickly as possible? This book shows how to solve this problem.
Farley, David; Humble, Jez (2010-07-27). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Kindle Locations 601-603).
Traditionally, software professionals obsess over requirements and development. The book focuses on the delivery of software, an often neglected aspect that’s ripe for improvement. Improvement that can lead to a significant boost in productivity.
If one’s purpose is to bring good ideas to market, as the opening implies, then neglecting delivery will negatively impact how quickly one can do that. And the book does indeed present a plethora of techniques to expedite the delivery of software. As the authors point out:
to achieve reliable, rapid, low-risk software releases that get the fruits of our labors into the hands of our users in an efficient manner.
(Kindle Locations 606-607).
But, what is a good idea? And why is quickly delivering a good idea the most important problem software professionals face? The first chapter goes on to discuss the consequences of neglecting the delivery of software, of an inefficient delivery process. And it discusses many of the benefits, of which the following is perhaps the linchpin:
Delivering fast is also important because it allows you to verify whether your features and bugfixes really are useful. The decision maker behind the creation of an application, who we’ll call the customer, makes hypotheses about which features and bugfixes will be useful to users. However, until they are in the hands of users who vote by choosing to use the software, they remain hypotheses. It is therefore vital to minimize cycle time so that an effective feedback loop can be established.
(Kindle Locations 793-796).
But, is acting upon an idea as quickly as possible the best way to validate an idea? To suggest it is the most important problem software professionals face, seems to suggest it’s the only way software professionals can validate an idea. This is no doubt true for many professionals because they aren’t involved in the decision making process.
The authors make a clear distinction between the customer who hypothesizes and decides, and the software professionals that carry out the decision as quickly as possible. For many organizations, this is an unfortunate reality.
But, for those that can be involved in the decision making process, acting upon an idea is simply one means to validate an idea. It’s one of several techniques. Having a conversation about what would make the idea worthwhile and the likelihood of success is another technique. Discussing the purpose of an idea and exploring alternatives is yet another technique.
These alternatives, albeit inefficient in terms of quickly delivering software, can be highly effective at determining what is likely to be a good idea. And they’re a great way to eliminate bad ideas that may seem like good ideas at first glance.
If software professionals relegate their responsibility to the delivery of feature requests, then efficiency may appear to be the most important problem. In comparison to the inefficient delivery of feature requests, especially drawn out projects, efficiency gains will significantly boost productivity.
But, speeding up the process of delivering features doesn’t fix the underlying problem that features themselves can be unnecessary. That good ideas are often just ideas. In fact, the authors, like myself, lament the many experiences we’ve all had with the prevalence of features that go unused.
By expediting the implementation of ideas, we’re more likely to streamline our landfills than to create value for customers. Efficiency gains tend to lower the bar from good ideas to just ideas. What was once painful, seems less painful. Less pain leads to less risk, which leads to a let’s see what happens approach. Especially if there’s not much accountability in validating ideas before acting upon them.
If software professionals see themselves as burger flippers, they can indeed learn how to flip burgers faster. They’ll deliver orders quickly and burgers will be cheaper. But their customers may just end up fat.
If however, software professionals leverage their expertise to be a part of the decision making process, then quickly delivering good ideas is no longer the most important problem. Nor is it perhaps even a big problem. It becomes an implementation detail.
A bigger problem will be effectively contributing to making wise decisions. For many organizations, accountability and responsibility to make decisions is concentrated among a few people. Software professionals are often treated as resources, much like burger flippers. That’s why pursuing efficiency holds so much appeal. Management and even software professionals see it as a means to boost the output of their human resources.
Changing this is much more difficult than evolving a strategy to quickly deliver features. Not only is it more difficult, but it has the power to be much more beneficial. Why? Because being a part of the decision making process significantly boosts the likelihood that the ideas are the right thing to do in the first place. No amount of efficiency will ever improve a situation where people are doing the wrong things.