Recently, my Slack app Jukebot hit some traction after @alexdebecker and I decided to launch it on Product Hunt. This was a great experience (one that we will write about at a later date) and delivered a whole load of new signups.
What's the Problem?
With a great number of signups comes an even greater number of support emails and feature requests. This is not easy to deal with when you’re only able to work of the project during evenings (when let’s face it, you’re shattered) and weekends (when let’s face it, you’d rather be spending time with the family, sleeping, drinking, exercising, socialising or all of the above).
Before you know it, you find yourself using every spare minute to smash out features or squash bugs. This is what I have come to call ‘no-time development’. It’s when you have no choice but to get things done and get them done quickly.
I suspect you can guess what is coming next…
During the Jukebot launch, I was busy crunching through some new features when I mis-typed a loop that made it’s way into production and caused one of the bot’s slash commands to make an API request 100 times in succession. Whoops!
The issue was quickly resolved and no harm was done. In fact, the bug didn’t affect users at all, but caused us to hit some API limits which would have been a problem later down the line.
Learnings
The real question here is, how do you deal with writing code after a long day at the office and under extreme time pressure? Like most things, I’d argue that there is no defined answer to this and ultimately, we just have to do the best we can.
Jukebot is 100% free for customers, so I don’t beat myself up too badly if I introduce a bug or two. It’s my toy - my place to learn and experiment so I take the view that I’ll ship features quickly and regularly to keep users happy and engaged, whilst iterating, refactoring and improving as and when time allows.
However, this particular bug did make me think, ‘what would I do if I was charging for this service?’ I came to the conclusion the story would be very different.
In my opinion, once folks are handing over their cold, hard cash, they are entitled to expect a seamless experience. That said, we are equally entitled to generate income from our endeavours. I mean, at the very minimum, we have costs to cover.
Ultimately, I think this means that we just have to be a bit cleverer with our time. It might be possible to fix a bug or two in the evening, but it’s probably pushing it to build out a whole new feature. Probably, it’s more sensible to save tasks like this for when there is time to really get into it.
Or perhaps it’s a better idea to increase time between release-cycles so that there is time to ensure everything is working as it should before shipping. This could have the side-effect of frustrated customers who think you’re ignoring their requests.
This is just a fun story to show that infinite loops happen to the best of us! However, it’s also been extremely thought provoking and I’d love to hear your thoughts on ensuring quality when working with time constraints.