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.

SCM

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.

Life at Google

One of my favorite bloggers is Steve Yegge. He initially worked at Amazon. Now he is with Google. A few years back he wrote a post bashing Agile. That was not the real story. His advice for developers is to work for a company like Google instead of using Agile methods. This was a firsthand look into the life of Google developers. Yes I have heard about the 20 percent side project work at Google. But Steve really gets down to the details of what it is like to work there. With the falling stock price, Google may not be the optimal location for the best developers now. But it is still interesting to take a look at a day in the life of the Google developer.

There are managers at Google. However they all write code. Furthermore they do not tell developers what to work on. Developers are self organizing. There are incentives to be part of a successful project. You have the potential to make giant bonuses and get stock options galore. This often translates into developers who feel like they owe Google. However there is also a drive to gain the respect of your peers at Google. Your peers also happen to be very smart if you work at Google.

Google has some environmental differences than your average development shop. It is very quiet there. You get free meals. Meetings are scheduled for the middle of the day so you don’t have to come in too early. It is kind of like a start up mentality. Google offers a lot of training. Some of it is formal. Most of it is not. There are apparently technical presentations going on all the time at Google.

On the development side, Google takes software engineering very seriously. There is a lot of emphasis placed on unit testing, design documentation, and code reviews. Some people just build developer tools at Google.

As usual, Steve generated a lot of comments from readers. Many people state that Google is unique in that it does not have paying customers who need software developed and shipped. Also Google has a lot of smart people. Google projects are financial failures. They just get a lot of money from ads in search. Google has deep pockets. If the Google model is so good, why does not everybody use it?

Capturing Requirements

I have written about a requirements gathering meeting with out client in my Software Maintenance blog. So I will not repeat a lot of the details here. However I did want to call to attention some details that might affect the success of our work.

The customer knows what the want business wise. However they do not know how to design or code the changes. That is why they have us. I keep hearing the customer try to understand the existing system, and design changes so their needs would be met. I continually attempt to focus our client into explaining to us what they business needs are. They are, after all, experts in their business.

Our customer has a lot of ideas about business needs in their head. At the meeting I attended, they were able to articulate many of those needs. This meeting was a precursor to the client formally requesting that we make a lot of changes to their software. I could not stress enough that they needed to write down the business rules for us. Unfortunately our requirements analysis team does not understand the customer yet. The requirements people are new. So we need the customer to write down their business needs. That is the only way we will have a chance to get the job right. The needs are extensive enough that just telling a few folks from our company about them will not do.

Code Review Redux

James Turner recently interviewed Alex Martelli at the O'Reilly Open Source Convention (OSCON). Alex is well known in the Python community. He is also a tech lead at Google. The subject of the interview was Code Reviews, which you know I have an interest in. So I thought I would go over and comment on the Alex's points.

The purpose of a code review is to catch errors. However a byproduct of reviews is also for developers to learn. Some things a code review can accomplish are to fix mistakes, ensure a uniform style of coding, check for good variable names, and factor our common functionality.

Obviously there are some shortcomings to the current method of conducting code reviews. Junior developers get intimidated by senior ones, especially when the old salts have big egos. In other scenarios the developers say nothing during a review. They have the attitude that they want to get out as soon as possible, so they state that everything looks fine. At the other end of the extreme are developers who nitpick every little thing they can with the code reviewed. Finally there is a lack of good tools to help code reviews.

Alex had some advice on how to improve the code review situation. He recommends that reviewers ask questions instead of criticize the developer. All people involved with code review should treat the activity as a way to learn. It helps immensely if the developers are humble and have integrity. And using software to assist the process is valuable. A tool which allows a reviewer to read the code, click points of interest, enter comments, and respond to comments is invaluable.

Alex also provided some examples of code review from the commercial community. Apaches uses an empty bug list as the signal to enter code review. Test Driven Development (TDD) seems to be taking the place of code review at many commercial development firms. However such techniques will not find some subset of problems such as race conditions and/or deadlocks. Pair programming also replaces code review in other locations. But after two developers have paired up for a while, it becomes hard to conduct independent review.

Prior to the interview, I had never heard of Alex Martelli. However I decided to listen to the video interview since he worked for Google. And I had respect for him having heard the insight he provided on code reviews. In closing he had mentioned the use of defect injection, where defects are randomly introduced into a system. The code review process is then judged by how many such defects are caught. Perhaps I shall try to introduce this technique into our own software development team. It might be a starting point to fix the movement away from code reviews on my project. I will let you know how that goes.