iPod and Dog: Jason Fried on Building Software

This ITConversations podcast by Jason Fried describes the experience of 37Signals in building BaseCamp, their web-based Project Management application.  His insights articulated many of my own thinking about building software, along the lines of 10 Steps to Building a Hugely Successful Web 2.0 Company.  It’s been a while since a podcast floated my boat like this one.  I had to listen to it twice and recorded some voice notes on my Axim on the second listen while walking the dogs.  Below are some highlights.

The first rule in building successful applications is to find the right people.  It’s better to have an average programmer who is positive than a guru who’s pissed off.  Need people who can do many things well, who you can trust to fix problems, and most importantly, who can write and communicate well, since most communication happens in the form of writing and IM.

Second rule is to embrace contraints, be they money, time or personnel.  Find creative solutions to constraints rather than eliminate the constraint by throwing money or people at a problem.  A small staff means that everyone is involved and responsible for their role in the product.  BaseCamp was built with one developer and two designers and started out as an internal project for 37Signals to manage their own projects.

Reduce mass.  Don’t sign long-term contracts, have too many developers and too much overhead.  Excessive mass prevents the ability to change and you have to be able to change all the time. Build less software, fewer features.  Don’t try to compete head-to-head with features.  Build something which is manageable by your own small team.  Technical support can “kick your ass.”  Less software, fewer potential problems.

People should be able to get basic work done with the product and have the flexibility to come up with creative ways of using the software.  The simple BaseCamp tasklist was given as an example of how users extended it for assigning tasks to others.

Look at how people are using the product in real-use scenarios, not in testing environments, to determine what features need to be added.  Look for patterns of use.  Let the software tell you when its time to add new features.

Version 1.0 should do half of what you want it to do.  In 30 days after launch release feature upgrade set.  Users know you are motivated, invested in the product and that it will evolve.

Scope reduction, not scope creep.

Don’t get too caught up in the details.  They can grind development to a halt and are often not as important as initially assumed.

You should be able to change every decision you make.  Every decision should be temporary.  Back to the need of being able to change the product quickly and efficiently.  Be able to “change all the time.”  Note from DBVT: Jason mentioned at this point how great web-based applications were because they were easy to change compared to desktop apps…which is why with Microsoft’s Click-Once technology in .NET 2.0 we are now building rich desktop apps because we can easily change them as often as we need to change them.

When you make a mistake, let your users know about it if it affects them at all.  Trust and honesty.  Quick resolution is of the essence.

It’s okay to under-estimate how many people will be using the product and build in scalability when you need it.

People who build the product should support it as long as possible to know what the issues are and to “feel the user’s pain.”

Article written by

A long time developer, I was an early adopter of Linux in the mid-90's for a few years until I entered corporate environments and worked with Microsoft technologies like ASP, then .NET. In 2008 I released Sueetie, an Online Community Platform built in .NET. In late 2012 I returned to my Linux roots and locked in on Java development. Much of my work is available on GitHub.