When To Software

I used to live above a cafe that sold smoothies. The smoothies were labeled smoothie A, smoothie B, C through H. My ideal smoothie would have been G without apples. I asked them to substitute the apples once, but they explained how they pre-mix all the frozen fruits and put them into pre-portioned containers so they couldn’t remove any one ingredient. This optimization was a trade-off for them:

Pros

1. This process is more efficient, reducing the overall work that goes into making one smoothie.
2. It reduces the amount of time it takes to handle an order when somebody is standing there waiting.

Cons

1. It increases the amount of prep work.
2. It makes the menu more rigid. No ingredients can be substituted.

Software as smoothie

Building software is like this cafe’s smoothie optimization. When we automate a process with software we make it more efficient. We reduce manual work and replace it with near-instant computation. We also make it accessible to more people. Web applications can handle instructions from around the world without any human intervention. However, software takes time to build (and even more time to get right) and has the downside of being very rigid. Computers, unlike humans, cannot make exceptions to their rules (yet!).

Let’s look at three different businesses

1. Business #1 is a classic eggs & bacon diner. It has a striped awning. Patrons are served by a waiter who scribbles their order on a notepad. They’ll cook your eggs however you’d like and are happy to make you anything they’ve got the ingredients for.
2. Business #2 is a hotel chain. Patrons are served at a front desk by a host that stands behind a computer. The host translates the patron’s requests into the hotel chain’s software. Sometimes the software is incapable of capturing the patron’s request. If so, the host is either able to make an exception — and accept the fact that the patron’s request won’t be described by their software — or they can deny the request.
3. Business #3 is a 1000x web scale software company (*cough* Google). Patron’s do not interface with any humans. If any of the patron’s requests fall outside the scope of the software, they are out of luck, the business will not serve them.

These businesses all operate within a different amount of constraint. Business #1 is flexible. Rules are passed via word of mouth and their menu (their core business offering) is non-contractual and can be changed without any resistance. Business #3 is extremely rigid. Their business logic is etched permanently in computer code. Due to their scale, changes to their business offerings are a tremendous lift and are very slow to execute. Business #2 falls somewhere in the middle. Around their core reservation software is a human workforce. Exceptions to their business logic are met with more resistance than in Business #1, but less than in Business #3.

While scale plays a large part in the rigidity of these businesses, so too does their investment in software. When processes are moved from manual operations to automated software procedures, they become codified. What used to be malleable is now fixed.

With scale comes rigidity

A software offering usually starts small, by automating one piece of the business. A shop could accept payments via a check in the mail, manually track inventory, buy stamps from the post office, etc. Likely though, they’ll want to replace those tasks with some sort of ecommerce offering. Understandable, computers are very good at doing this work and the barrier to entry is lower than ever. However, as the shop grows, their business offerings and requirements grow with it. Given that the web store is the interface to their offerings, their software must grow in parallel with their new requirements. We create new features and build on previously solidified business logic and assumptions. As we offer more to our customers, we too make our system more rigid.

This is not unlike any other building project. A subway system, for example, starts with just a few stations. As the city grows, the subway grows with it and the network of dependent stations increase. If we move station A, we also have to fix the connection between station B, C, and D. Older subway stations may not fit the requirements of the newer, bigger city, but oftentimes there is nothing we can do. They have too many dependencies and the traffic above-ground is too busy to stop for the amount of time required to replace them. We’d have too many unhappy commuters (customers), so we’re stuck with what we’ve got.

Code has two meanings

When coding a piece of software you are responsible for two different things:

1. Encoding business logic into a discrete set of procedures.
2. And translating this set of procedures into computer code.

As a software developer and entrepreneur, I am obsessed with step #1. I love to codify human business requirements into procedures. That being said, I am also extremely skeptical of it. I believe that all developers have the responsibility to be. When a client asks for a custom software solution, I usually step through the following decision tree:

1. Do we understand enough about the business requirement to automate it with software?
2. If we don’t understand enough about the business requirement, can we put together a low-fidelity solution that allows us to gain more insight?
3. If we wholly understand this business requirement, is there existing software that captures it completely?
4. If there isn’t an existing solution that captures the requirement completely, is there existing software that mostly captures the requirement and are the missing pieces important enough to justify investing in a custom solution?

The costs of efficiency

A realistic scenario is that www.exampleclothingcompany.com spends a lot of time processing customers’ requests to return their clothes. Given the amount of online clothing purchases that get returned, this may be one, or many employee’s full-time job. Example Clothing Company may want to automate this process. They spend a lot of time manually responding to emails, printing shipping labels, and even reiterating their return policy to their customers —

“We’re sorry, clothing must be returned within 30 days of when it was purchased. Please refer to our return policy”.

They want to invest in software to enable customers to send back their clothing and receive a refund with as little human intervention as possible.

To do this, we’ll need to codify their return policy. I’m going to greatly simplify the process for the sake of brevity, but in essence, we’ll use software to check if the time that the order was created is less than 30 days from now, and if it is, issue a refund and a shipping label to the customer. This saves Example Clothing Company a tremendous amount of time, but at the cost of rigidity. Attempting to return an item 30 days and 1 hour after it was purchased is no longer soon enough. Software, unlike humans, does not have humility. Somewhere there is a line of code that decides whether your refund is accepted or not and it returns a yes or a no, not a “Maybe. Let me check with my manager”.

This rigidity may outweigh its cons. A few unhappy customers may be completely worth the boost in efficiency. Smoothie Cafe thinks so. Google is happy making a one-size-fits-all software solution that serves 90% of people happily. Eggs & Bacon Diner however, may not be able to afford to lose the 10% of their customers who want their eggs poached even though it’s off-menu.

Is there another way?

Maybe we can strike a different balance. Maybe we can streamline the process of customers submitting a return request, but still have customer support personnel accept or deny it. We can remove some of the human intervention, but still build a system flexible enough to handle unforeseen edge cases. This solution may not be as elegant or as efficient, but it does allow us to learn more about our business requirements before we solidify them. There is no correct solution here, only one that strikes the best balance.

Knowing When to Software is a fine art. It is an extremely empowering tool (and a fulfilling journey!), but requires careful consideration. At Sanctuary Computer, we have extensive experience building and maintaining software systems that encapsulate a tremendous amount of business logic. Even still, we are skeptical before taking the plunge. We always look for simpler solutions, ways to hack it, steps that are more incremental and allow us to gain more insight, before building out a featureset. Hospitality is at the core of our ethos. We want to make sure that our clients are building the right things; that they aren’t investing time building features that don’t exactly meet their business requirements and expectations. We want our clients’ software offerings to feel like a precision swiss army knife, not the NYC subway system :)