When your bot gets retired

Bots are used all over the internet and are also used internally. There are a lot of specialized bots that are focused on a single responsibility to manage. The same is happening at SoftwareMill— we are running a bunch of bots to support our internal processes like hiring, controlling Slack channels, or even coping with employees’ moods on a given day.

Yet each bot reaches its end date and needs to be retired.

Photo by Erik Mclean  on Unsplash

Developing bots

There are plenty of tools to develop bots, each communication platform delivers a pile of proper APIs, examples, and ready-to-use artifacts. This also means there is no one strategy how to replace a bot with a newer, shiny version.

As Softwaremill is a 100% remote company, we are using Slack as the backbone of all our internal and external communication. Also, all our bots are using Slack as the main communication medium. A long time ago in 2014, I started our first bot using the Hubot project called Janusz The Bot (Janusz has some joke references in Poland ;-). Shortly after that, we decided to support our hiring process using another bot, the same Hubot as a base, called Halinka The Bot (another reference to a joke).

Awarding with kudos

Both bots had been extensively developed during those days and loaded with a lot of functionalities. With our company's growth, the hiring process has also been evolving, yet using a dedicated bot instance to control the process allows us to support the stepping-in changes. Another bot instance had been also loaded with priceless funny functions like brace yourself or CRON-like reminders. There were also other helpful things like the ability to add kudos for someone or support the 4th question asked at our company meetings.

Janusz is always on duty ;-)

New is coming

With company growth also the number of channels has been rising on our Slack, we decided to introduce a policy on how the channels should be named, what kind of description is needed, and how long a channel can be inactive. To control all these requirements we developed another bot — Woźny The Bot using a new BoltJS Slack framework. We already knew that Hubot is going to be decommissioned at some time and it doesn’t make sense to invest time into it.

Woźny at work with inactive channels

Another bot has been introduced to partially cover employees’ mood area and as well to take over some functionalities from other bots as we already know some functions won’t be used any further and some still need to be supported at some level.
That’s how Aniela The Bot has emerged using the BoltJS framework with Typescript support.

First steps with a new bot

Preparing for the change

Once we started developing new bots using a new framework we also had to prepare users. They should know how to smoothly start using the new bot and its command instead of the old one. This adds some extra work as at the same time you must still support both instances.

To be even safer and better prepared to introduce new or rewritten functions, we started using a dedicated test bot instance which allows us to run code locally and interact with it directly via Slack. This all was possible because a new Slack platform is preferring the WebSocket mode instead of the dated Real Time Messaging API.

Aniel’a alter ego — Angel :D

Anyway, so after developing a small part of functionality — let's say adding a new 4th question to the pile, which was previously supported by a command in Janusz The Bot, this time we used [Slack Slash]() commands https://api.slack.com/interactivity/slash-commandsto interact with the new bot. Having tested the new slash command with the test bot we were able to start using it in production, yet no one knew about the command :D

We had to inform users that instead of using an old @Janusz 4th add ... syntax they have to use the new /4th_add slash command and the obvious choice was to let them know directly by Janusz about that. So we changed the code in Janusz to inform about the new slash command each time someone will try to use the old command — not rocket science but allows users easily transfer from using one tool to another.

Don’t let users alone

Using this approach we can learn users about the new functions replacing the old and perform migration in steps without disrupting users. Users hate changes, so you must be gentle when introducing them.

Final word

You shouldn’t be afraid of possible migrations, it isn’t an easy task so preparing a plan makes sense (even if you won’t follow it). Focusing on users is the most important part of the whole process. Making them confused with new functions, not giving a hint of what’s going on, or avoiding extra work just to save money will hit you twice more in the future. Systems and programs are constantly changing and migrating from an old version to the new one is a natural thing in the digital world.

Just keep your users at the center.