“Do one thing and do it well” — Does classic Unix apply to bots?
It’s hard to argue against the success of Unix derivative operating systems in the server market. According to thecloudmarket.com, which tracks cloud giant Amazon’s instances, over 90% of Amazon’s cloud servers are Unix based.
Many qualities are responsible for that success yet a large component, especially in early growth, was due the modular nature of the system as opposed to the more monolithic competing operating systems.
“This is the Unix philosophy: Write programs that do one thing and do it well”
-Doug McIlroy, a key founder of the Unix tradition
Should chatbots strive to do only one thing and do it well?
There are good arguments to be made both for and against.
For
More Constrained Domains Easier to Get Right
Conversations that are fully open ended in scope are still extremely challenging to do well. It’s amusing to poke fun at Apple Siri’s mis-steps until you try to make your own more generalized conversational experience and fall far short. IBM’s Watson, Facebook’s Wit.ai, and Microsoft’s Luis.ai are a jumpstart but not a panacea either.
The trouble is when you bot can do too much, your world of potential context and operations explodes. You become greatly limited in your ability to infer intent and channel your users to supported functionality when they could want to do any number of things.
Remember, conversational interfaces typically do one thing well — in this case, order pizza — so the trick when designing one is to make sure to build conversational guardrails to keep the chat going in the right direction.
-Jenny Clark at hugeinc.com
Faster Time to Market
VentureBeat opines that the chatbot gold rush is officially here. Time is of the essence and doing one thing is clearly faster than doing multiple things. You’ve got to stake your claim quickly, right?
Easier to Build Straightforward UX
Adding too many features rather than focusing on one thing increases the cognitive load on your users for figuring out and remembering how to interact with your bot. Will they figure out the workflow you intend? Seeing so many features could set an unrealistically high expectation of completeness and be counter-productive. The user could be inspired to try many more things and be met with frustrating dead ends or imperfect results.
Interacting with chatbots in general is new to most people. Many people have still not mastered the art of masterfully crafting their question into just the right Google query. Google even created a class on power searching! Keep it simple at least until new paradigms become familiar to users. It would have been a failure had Apple introduced the iPod Touch with multitouch gestures as its first touch device.
Against
While the comparison between platforms enabling chatbots and Unix systems is useful, there are nonetheless fundamental differences that can cause differing outcomes using the “do one thing well” strategy.
Bots Can’t Work Together… Yet
Doug McIlroy invented Unix pipes which connected those small Unix utilities together and let them hand off work to each other seamlessly. The resultant value of joining together permutations of various utilities was tremendous. This is missing in every current bot platform. You can’t neatly piece together a workflow in a standard way across a number of bots. Bots can at times be present together in the same room or channel, but they cannot seamlessly work together over a clean communication channel. Bridging this gap is actually a tremendous opportunity for all the platforms but especially Slack. Imagine your agile coach bot having your calendar schedule bot book a retrospective meeting with the members of your channel active during a release. Until then though, your users must keep ferrying commands and messages between their robot army which is not ideal.
Bundling and Ecosystem Effects Missing
Another difference is most Unix variants benefit from an in the box bundle of the popular utilities via POSIX or LSB agreements. You don’t have to go searching for and installing the various utilities and can count on them being there. Also, other developers count on the utilities being there and shareable scripts tying them together come out.
Without the bundle effect in bot platforms though there is no cohesive expectation on what bots are present as a base. Additionally, there’s also a mental drain for users to keep track of various bots to individually add and manage.
Management and Organization of Many Bots Still Nascent
Current tools for rapidly adding, authorizing/de-authorizing, and keeping track of many bots are still not ideal. Your Slack screen can get pretty crowded managing a large number of public channels as well as direct message channels to a large number of bots.
Imagine what your kitchen would look like if you were an infomercial and gadget addict and bought every amazing single purpose tool. You’d have a mess on your hands finding a spot for your avocado slicer, banana slicer, apple peeler, panini press, etc. Though the digital world is less limiting than the physical, organization and use of space still matters.
Conclusion
There is no clear winner as the arguments for both sides have merit. As with many things, moderation is the key. Given the current limitations of the chatbots platform, you don’t want to go too far towards either extreme of single purpose or a confusing muddle of features.
Aim to be the George Foreman grill of chatbots focused on the indoor grill use case but handling meat, fish, vegetables, even being a panini press.
Avoid creating Pizza Scissors. You’ve never heard of them because they’re discontinued. Apparently solving the problem of not having a single tool to both slice and carry your pizza just wasn’t important enough.
