"The Building of Basecamp" Review

Other
Jul 05, 2004
by Calvin Correli
1 min read

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.

Like

About Calvin Correli

I've spent the last 17 years learning, growing, healing, and discovering who I truly am, so that I'm now living every day aligned with my life's purpose.

Read more
Read next

Digging

7 comments

Aaron Swartz
 

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?
Read more
Read less
Reply over 20 years ago
  Cancel
Aaron Swartz
 

RSS feed Your comments should have RSS feeds or email notification so I don't have to keep checking to see if you respond.
Read more
Read less
Reply over 20 years ago
  Cancel
Aaron Swartz
 

Email me I'm tired of monitoring this page so if you ever respond to this comment, email me.
Read more
Read less
Reply over 20 years ago
  Cancel
Jarkko Laine
 

Re: Just say no <p>Aaron, </p><p> 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". </p><p> 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". </p><p> 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. </p> <p> 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.</p>
Read more
Read less
Reply over 20 years ago
  Cancel
Lars Pind
 

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.
Read more
Read less
Reply over 20 years ago
  Cancel
Jarkko Laine
 

Jobs seems to agree Seems that the Basecamp folks <a href="http://www.37signals.com/svn/archives/000887.php">are not alone with their opinions</a>.
Read more
Read less
Reply over 20 years ago
  Cancel
Jim Gladstone
 

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 <a href="http://www.chmuraecon.com/OnStage/">OnStage</a>, a very similar but slightly better design system, IMO.
Read more
Read less
Reply over 20 years ago
  Cancel

Leave a comment