The hallmark of the software professional is that they often see a world where technology has almost infinite capacity to improve our lives. Software can’t put food on a plate, but it can help calculate the most efficient way to grow and distribute the food. Software can’t give us a hug (yet), but it can put us in touch with our loved ones. So when you’re building new software or new functionality for software it’s an opportunity to automate all kinds of things that used to be difficult and arduous processes.

Except, that’s not always the case.

Here’s an example: A service we worked on had the ability to sell digital content a la carte or as a subscription. Originally the service was designed to sell only a la carte. And that process was automated completely. But when we wanted to experiment with a subscription it was a significant amount of engineering work to make it happen. We made the investment that let users pay once and consume unlimited content. But the payment processing work was not done and we wanted to try it out. Originally we thought of this as a compromise, but we realized later this was in fact a boon. Why invest significant time in automating the commerce for subscription purchase if the subscription experiment was a failure. We were able to do the bare minimum of engineering investment to find out what customers wanted. And only after determining that subscriptions made sense to our audience did we need to convert our manual/human-driven fulfillment process to a digital one.

This is the kind of step that’s often missing at tech companies. After all, why do something manually when code can be written to automate the process? Of course, what’s not considered int his calculation is: the likelihood that the functionality will actually be used, the cost to test, update, and maintain the code, the potential churn to other parts of the codebase, and how those latter two costs go up if the experiment turns out to be a bust.

The silver lining of doing a process manually for awhile is that you end up with a much tighter and more solid design of the functionality eventually to be enshrined in code. Actually walking through the commerce process let us know what was actually necessary when writing the code for the functionality. Typically when you design features you’re guessing. It’s often educated guessing, but guessing nonetheless. Now we knew exactly what the functionality needed to do because we’d done it ourselves, by hand.