Start a StartUp / Blog

I’ve read through the Getting Real book and “Less” is now imprinted on my forehead. Less software has all the advantages of being:

• Easier to develop
• Easier to understand by the user
• Nimbler to change
• Simpler to use
• Focus is on the core problem
• Incentive for creativity
• More iterations thus shorter feedback loops and better control
• and all the other goodies.

If you haven’t read Getting Real, go grab the book now. However, let me tell you, there is one important question that the Getting Real book fails to give answers to.

What if I want the app to be a little different? Can’t I change the applications I use? Am I locked in into the designer’s way of thinking? What if I have a better idea to make it simpler and better for my need? I’m not dumb, dammit!

Let me give you an example to explain my frustration. We started using Basecamp and loved it the instant we got started on it. Initially we used it the way it was intended by the designers. We exchanged messages in the message board, each person created own tasks in the to-do lists and the project manager setup milestones in the milestones tab. We have a scrum meeting daily and each person says what he did yesterday and the scheduled tasks for today. As we got used to it, we found ways to improve our process.

One problem was; promised tasks for today rarely got completed because there was no one keeping track of who said what in the scrum and who kept their promises. Now we made minor changes to our process. During scrum time, everyone creates tasks under a new to-do list with today’s date. At the end of the day the product lead goes in and sees who missed their tasks and puts their name in the title. The name of the person who missed the tasks and the date is permanently archived on the side pane in Basecamp. Let me tell you, this created wonders. No one wanted their name to get blacklisted. We drove ourselves to complete what we promised. The foresight of Basecamp’s designers gave us enough flexibility for this issue.

This hack worked fine in the current Basecamp, but we had more ideas. What if some team members checked in low quality stuff to meet today’s deadline they set for themselves? Can we keep track of how many tasks got reassigned? Can we link our checkins in subversion to Basecamp? We currently do this in an even more clumsy way. We raise comments on messages when there is a quality issue with a closed message. There are other ideas we needed but we were locked in to what the designer gave us. We use base camp a little differently than the way it was intended. This is a hack that barely works.

The solution obviously is not to give as many features as possible in one application and let the user configure them. Look at this Microsoft Word screenshot with all the features enabled. No one really uses more than 20% of those features. We would loose all the advantages of “Less”.

Kathy Sierra posted an excellent post, as usual, on feature requests. “Don’t give in to user demands”, she says. I get the point. Don’t try to implement every thing users say because saying is easy. Shouting is easy. Screaming is easy.

A better way to solve this issue is to raise the barrier to a feature request. That is, if some one wants a feature, just saying it should not be enough.

One solution that has worked great is plug-ins: Firefox, rails, wordpress, movabletype, apache, etc all make great use of plugins. What we really need is plugins for web apps. Web applications have an API, but that’s just access to data. The app is the UI, not the API. I want to change the app. I want a plug-in for web apps that can change the UI. Notice that plugins not only give access to the data, but also to the UI. Opensourcing the application and creating some sample sharable plugins should be enough to kickstart this idea. However there is the issue of hosting third party code on your server.

Another way, is to architect the main application as a client which uses api from a central data store. Open source it and let others write and host applications of their own if they want new features. Since the cost of the application is low enough, the pain of hosting it and maintaining it will be enough deterrent for normal users to host their applications. This application will just be a view to the data that is stored in the hosted application. But code is repeated all over the place.
May be plugins + opensourced client would work?

Also, how about greasemonkey scripts? Nah, too hackish. Will break frequently.

Customizing an application is an effective barrier to competitors. The more customized versions of your app out there, the harder it is for a competitor to get in. Competitively it’s a bad strategy to not customize your application as it makes it easy for competitors. There is only one app they need to replicate to get in the game. Its high time to find a solution to this.

It’s a tough problem! Well if it was easy, someone would have solved it by now.