When we envision creating software, we usually have an end-goal in mind. And that envisioned end-goal is usually wrong. It’s probably missing highly valuable elements, and it’s almost guaranteed to be overbuilt in areas. Let’s explore how this happens, and how we can keep this from devouring our budgets and still leaving us wanting.

Let’s imagine a fictional company. They’re going to disrupt the auto detailing industry by improving and automating their current successful business in Kansas City, and then spreading to other cities. A key component of this strategy is software to automate as much as possible so that the humans can focus on keeping their customers’ cars looking their best. So, of course, we can think about all kinds of features, like helping customers book appointments, accepting payments online, estimating cost, and keeping track of coupons and promotions. We might even think farther down the road with more advanced features like managing inventory in the detailing shops and predicting when to do more hiring. It’s easy to think “kitchen sink” when planning software development in this way. We’re doing a big project, we might as well plan for everything we can think of, right?

We could set out to create software that does all of those things, and it may cost $1 million or more to build it. That’s a lot of money. Likely, it’s big enough that the business would need to finance the development somehow. It’s an existential gamble: if this software investment fails, it will likely tank the business. It assumes that the business strategy behind that envisioned software accounts for every hard-to-predict factor. Market forces, consumer behavior, economic ups and downs, and countless other influences can seriously impact how well or how poorly this software pays off.

We could do this, and hope that the bet pays out. Or, we could put the risk and uncertainty into the forefront of how we both plan and execute the development of our software.

Let’s say we first build only an online booking tool (for far less cost), and then begin using that in our existing detailing business. We may learn that many customers start booking monthly or quarterly appointments a year in advance. We can make a couple of observations about this. One, we could offer discounts for pre-paid packages of four or twelve detailing appointments since predictable, pay-ahead revenue is more valuable than ad hoc bookings. And two, we can use the future bookings to predict when we need to hire, add shop space, and so on. These insights we gained by building just a portion of the envisioned software. What’s more is that these business insights and opportunities may already be valuable enough to cover the cost of developing that limited amount of software.

Continuing to evolve the software to add more features and reap richer insights is, now, a matter of continued investment in an increasingly profitable software asset. What’s also true is that continued evolution isn’t bound to the initial plan we set out to build. Step by step, we can evolve the software based on the most important, real, observed needs and not on predicted or imagined needs. We might discover that inventory management isn't such a problem that it needs automation, and that we need more sophistication in online booking, payment processing, and customer communications instead.

This is the essence of evolutionary software design. Rather than budgeting and planning for a Big Design Up Front (BDUF), it's often more profitable and less risky to start simple and evolve. The forces that dictate what software features deliver the most value are hard to predict. Rather than making big bets on large batches of features, it's often better to make small bets and re-evaluate often.

Let's explore this by way of a metaphor. If someone suggested, "I need you to design me some shelter," we could spend time envisioning a house of some kind, specifying all the details we could think of, and then begin construction. That construction could take months or even years: time spent without that shelter.

Instead, evolutionary software design would suggest that, initially, it might be worthwhile to construct a simple tent, and evaluate how well that simple tent addresses the needs. Using a tent for a few days would yield some insights that we should use to steer how we evolve our shelter further. A simple tent obviously lacks plumbing and the opportunity to accommodate most furnishings like beds and tables. However, a tent does make it convenient to relocate as often as daily. If the discovery of this convenience (and the value it generates) becomes important, an evolutionary approach can accommodate it easily. Perhaps evolving a tent towards something like a camper trailer would solve the issues of plumbing and comfortable furnishings while also keeping the convenience of moving the shelter from one place to the next. Let's also not forget: we learned these insights by using the tent; that is, it's already providing value as a shelter.

If mobility happens to be a key value-producing element of a business, the BDUF approach would likely eliminate it as a feasible possibility. Furthermore, each evolutionary step can still produce value in the real world. We don't need to wait for concrete foundations to cure, walls to be constructed, and so on before we get at least some value from using our simple tent for shelter. We also don't need to build an entire house before we learn that a camper trailer would produce more value.

Obviously, the cost for a tent is far less than the cost for a house. And, in software, the cost for incrementally evolving a tent remains low, allowing you to reach return-on-investment far faster. Choosing to build a house assumes that today's insights are accurate and stable enough to justify a large, slow-moving investment. Such large, slow-moving investments can't accommodate the discovery of high-leverage opportunities. Discovering new insights in a BDUF environment tends to create broken plans and waste. Discovering new insights in an evolutionary design environment tends to produce stronger plans and more value sooner. Don't make big bets. Start simple and evolve.