What doesn't matter
Posted by David Harris Mon, 20 Feb 2006 20:31:00 GMT
On the recent SvN blog by 37signals, I was a little perturbed by the people posting comments there.
I thought by now people would be embracing agile standards, less software, and good design principles for maintainability. But apparently some people are lost in wading through the older school of thought that more features makes a better application.
And sometimes, more features do make a better application, if and only if the application cannot survive without those features, or it would diminish the ability for the user to operate the software.
Especially on the web, less is more. There are millions of applications out there, and you are not going to make your mark with the application that does everything. The way you survive, and even thrive, is by making a great application that does one thing perfectly, and paying attention to how your users are using it.
The most valuable thing I have learned is that you cannot use agile methods by asking the user what he needs. Why? It’s very simple: the user doesn’t know what he really needs. The user DOES know what he has seen elsewhere, and will always ask for those sort of features. But what they really need is not those features, but it may be a completely different feature that does a better job than the one he thought of.
The way to go about that is not asking your users what they need, it’s to listen to their complaints, consider what everybody is saying, and find a way that solves it creatively and in a better way than they are asking. If people are asking for timestamps down to the microsecond, why are they asking for that? Well, in the end it may be just to uniquely identify each record to point it out to others. Yet this same problem can be solved in less code with simply adding an anchor to each post and providing a hyperlink generator. Or perhaps you can “tag” a record a certain way, and let people look for the tags. Or maybe clicking a record highlights it, which not only saves your favorites, but also could provide a way to see what you deem as important.
Obviously it doesn’t stop there. In web software, we have to figure out a way to keep feature creep out. The best way I know of is to just say no. Develop a list of boundaries for your software, and adhere to them. Define what your software will and won’t do at time of release, and only deviate in extreme cases or when you think the product will actually benefit. Users eventually dictate the course of a product, but in the end the developer is the artist. As a musician, do I make music for other people, or myself? Only the former if I’m a sellout. I can make a lot of profit and have a gargantuan behemoth of a Web 2.0 taggable application that really just sucks the life out of me. And where is the programming joy in that?! Give me something I love to work on any day over an application that fills every need a user might or might not have. In the end, my ability to fix the application is more important than the trends and whims of my users.
