four bean soup

The other day I was poking around on an old server that I am getting ready to retire. I ran across some ruby scripts, the very scripts that spawned the idea that is now tweethopper.

Me, Myself, and I

I saw a post on 37signals blog ^[1] recently that talked about adding features to instapaper that only the developer needed - I couldn’t agree more. When you start adding things you don’t need or won’t use, you put much less thought into it, which can have disastrous consequences for your app.

Build what you need

Building something you need helps you focus on the important parts and you build something that is opinionated. These opinionated views and approaches can make your application strong and differentiate this app from others.

When I built tweethopper, I was tired of the non-scalable method of copy and pasting script files, editing them, adding them to cron, etc. I wanted a convenient way to quickly setup a new twitter account and give people the ability to have a group control the tweets. Moving from a ruby script to a rails website seemed the natural progression.

After building the first iteration of the service, we started looking at other ways we could use the tools to help our workflow. Feed tweets and Auto Follow features were added as we discovered they could help in running our business.

Unintended consequences

I recently added a feature I didn’t need to tweethopper, I had a number of users asking for custom bit.ly api key support. I hooked up all the code, added some text boxes to the forms, and launched the new feature.

A strange thing started happening after launching. People would sign up, only to cancel within a few hours. I decided to finally email someone who cancelled to ask them why they did - his response was “I don’t know anything about apis!”. Baffled, I started poking through the application. Lo and behold, it was the new bit.ly api key fields that had scared him and others off.

Bug squishing

When you add a new feature, you test it. In my case, I wrote plenty of unit tests around these features to ensure they worked. I tested everything from terminal on my local machine. I didn’t actually use the feature in the live application because I didn’t need it.

Had I taken the time to use the new feature, I would have seen the small bug that users would run in to. When you copy/paste the bit.ly api key from their website and input it to tweethopper, and extra space comes on the end. If the space is left on, the bit.ly api won’t let you login properly. This leads to is.gd being used to shorten links instead of bit.ly in our application. A simple ruby chomp call fixed this issue right up.

Sometimes it’s good to say “NO”

Using “NO” is a very valuable tool. Being opinionated is an important method to control the function and flow of your web app. The goal isn’t to turn down every feature suggestion you get, they should be explored. Just implement the ideas that make sense and you will use yourself.

Links

[1] 37signals post