Lessons from 37 Signals

37 Signals is a successful start up company. They have a number of rapidly developed small products which they sell. I have read a white paper from them on the lessons they have learned from their experience with software development.

They recommend you keep projects very short. We are talking about the order of 2 weeks or so. They advise against project plans which are set in stone. 37 Signals does not believe in design documentation or functional specifications. That seems like a radical idea. They also tend to focus on what is real as opposed to abstract theories.

Regarding content, 37 Signals likes to focus on things that are constant. They want to solve problems which will be encountered for the next 10 years. They also believe in sharing ideas with the public so that others may learn. Here is an idea which is not new. 37 Signals believes that you should “question everything”. I could use that advice myself. Having programmed for many years, I carry a lot of baggage in the form of untested assumptions.

37 Signals believes that there is a time when you should give up on a problem which is hard. They also back the idea of working 32 hours a week instead of 40. When you think about it, that is not so radical when compared to the Tim Ferris 4 hour work week. In terms of timing, 37 Signals thinks you should release the best half of your application first.

According to this company, client work is depressing. I second that motion. You can work hard to solve a specific problem for a client. However in the end, all you get to do is charge for those hours. You are not building a cash cow. I would like to end on a funny perspective from 37 Signals. They have no formal training program. Their method is to just drop people in the pipeline and hope they figure things out.


There is a book online by Eric Sink about source control. You would think this guy knew what he was talking about. He founded a company that produces source control software. I thought I would share some of the things I learned or recalled while reading his book.

The first order of business is defining source control. It is also called version control or SCM. This let’s developers work in parallel on the same code base. You must learn how to do this. You don’t get taught this at college. Some example of source control systems are SourceSafe, Subversion, CVS, and Perforce. The product created by the author Eric Sink is Vault.

Source code gets stored in a repository. You can get a copy of the code to view. You can also check out a copy of the code. The repository will automatically merge your changes in with changes from other developers. How is this repository maintained? It can store the whole copy of every version. However that is not very space efficient. Instead I believe most repositories only store the deltas between each version.

You normally have the ability to name a certain version of a file or your whole code base. This name is called the label. Another idea in source control is branching. This is where you have two or more copies of your code base at the same time. The good source control systems are integrated right into your IDE. I must confess that, even though my own source code tools integrate with my IDE, I do not use this functionality. I prefer to do things manually myself.

Complex Requirements

I recently checked out an article by Scott Ambler in Doctor Dobbs magazine. And I paid attention because his name sounded familiar from the past. I think he may have written about C++ in the past. From his bio, he is into process and agile methods. His article affirmed that requirements are complex, but applying Agile to them can help.

We do not want a heavy level of documentation for requirements. Take an example from Scrum. They have something called a backlog which prioritizes requirements. This is a good methodology to manage simple requirements.

You would think that complex requirements could be broken down. The problem is that if you do break down the requirements, the smaller pieces might not make sense by themselves without the context. You need to try to group the smaller sets of requirements in a smart fashion for this to work.

Just like traditional object oriented analysis and design, you should break the requirements into use cases and scenarios. The use cases should be simple. There should also be very little documentation.

Agile Evangelism

I read an editorial lately about the relentless evangelism by the Agile tribe. Their attack on traditional waterfall methods is vicious. Sure many software project fails. But don't Agile projects fail as well? I doubt anybody is keeping track of this. I put a picture of Wendy Friedlander up for your amusement. She is one of the agile evangelists out there.

Software projects worked before Agile came around. and they will continue to work after Agile has come and gone. So what is there to truly tie any success to the Agile methodology? As you can tell, I have a lot more questions than answers here.

I am big on unit testing myself. That does not mean I advocate Agile methods. Unit testing itself is not a new technique created by the Agile movement. I will say that I like some ideas behind Test Driven Development (TDD).

One of the blogs I faithfully read is Joel on Software (Jos). Most of the good stuff comes from comments posted by JoS readers. It is funny that Joel has blasted Agile for the main part. He says that you cannot accomplish much when you are writing endless unit tests. And if you don't know Joel, he is big on getting things done.