Lars Pind

internet software, coaching, and entrepreneurship

Lars Pind - internet software, coaching, and entrepreneurship
Check out Coach TV, my video blog on happiness and personal development for geeks.
← Banterist - Field Guide To Online Dating Profile Photography Digging →

"The Building of Basecamp" Review

July 06, 2004 · See comments

http://www.gadgetopia.com/2004/06/29/TheBuildingOfBasecampReview.html

Talli sent me this link last week, and it’s been rumbling in my head since.

This guy’s list of main points are completely in line with my current beliefs about how to develop great software, in particular these three, which I’ve quoted verbatim:

  • Say “no” by default to any feature request. Make a feature work very hard to be implemented.
  • Start everything with the screen design. The screen IS the application. The screen drives the functionality, not the other way around. The screen design is the requirements document. (I know, I know — the hair on the back of your neck just stood on end…)
  • Avoid preferences. Preferences can be cop-outs to tough problems. Whenever you have the user set a preference, you’re having them make a decision (Joel Spolsky’s book is big on this too). It’s more challenging to come up with a solution, and mandate it. As a result, Basecamp requires something like four fields to be completed and it’s ready to go.

blog comments powered by Disqus

Comments ↓

  • 1 Aaron Swartz // Jul 25, 2004 at 07:18 PM

    Just say no Saying no to every feature request sounds like a bad idea. What's the reason for it? One reason might be because complicate the interface, but I think most features are either largely invisible (think IMAP support for Gmail) or an improvement to existing functionality (think better MIME parser). Another is because it complicates the code, but with a good language and refactoring this isn't much of an issue. So what's the reason for this rule?

  • 2 Aaron Swartz // Jul 25, 2004 at 07:23 PM

    RSS feed Your comments should have RSS feeds or email notification so I don't have to keep checking to see if you respond.

  • 3 Aaron Swartz // Aug 20, 2004 at 05:49 AM

    Email me I'm tired of monitoring this page so if you ever respond to this comment, email me.

  • 4 Jarkko Laine // Aug 24, 2004 at 12:42 PM

    Re: Just say no

    Aaron,

    I can see your point. However, I don't think the idea is to say "no" to each and every feature request. I understand it rather so that "no" is the default answer unless there is a very strong reason to say "yes".

    One very good reason for this rule that I can think of is that the clients tend to be quite eager to come up with new feature ideas, long after the project has begun and a lot beyond the original requirements. I'm not saying that the original requirements document is the word of God (it is not), but implementing everything that's asked for can easily lead to massive bloatware like MS Word or TOAD that I wouldn't describe as "great software".

    Another reason that comes to my mind are the project management issues that can be expected to arise from too loose politics by the implementor.

    Also, I think that in order to such dogmata being obeyed even partly, the rules must be somewhat extreme and contradictory, so that they get the attention they deserve.

  • 5 Lars Pind // Aug 31, 2004 at 11:32 AM

    Saying no It's not "say no", it's "say no by default". Instead of the standard defaulting to "sure, we can do that", take the time to think it through, and make sure the new feature is actually required, for example: How frequently does the need for the feature arise? Are there any workarounds? How much does performing the workaround as opposed to the proposed feature cost to the user? How much would the complication of the user interface cost the user? How much will the extra feature cost in development, maintenance, etc.? How well does the feature resonate with the goal or filosophy of the product? Would it alienate some of the users you're trying to attract? Of course you need features. Features that measure well on the above questions should be implemented. Features that don't shouldn't.

  • 6 Jarkko Laine // Oct 14, 2004 at 11:00 AM

    Jobs seems to agree Seems that the Basecamp folks are not alone with their opinions.

  • 7 Jim Gladstone // May 12, 2007 at 11:33 PM

    While I think basecamp's overall concept is great (I used basecamp for 2 year), there were some things that seemed small at first but ended up driving me nuts. Fortunately, basecamp has some good competition now. I recently just switched to OnStage, a very similar but slightly better design system, IMO.