Bus Factor = 1

I haven't been as prolific on this blog as I had hoped a few months ago, but thats how life goes. You get busy with school and you don't have time to write. Since I have a few minutes I thought I would write quickly about something I learned at the end of this quarter at Neumont.

Always bus-proof your projects.

Many of you developers know what I'm talking about, but I'll explain what I mean by "bus-proof." Think about a development project that you have been on for a moment. If someone on your team was hit by a bus, would the project be able to continue? How many people would have to be hit by a bus until the project couldn't continue? Thats basically the entire concept of the bus factor of a project.

I learned the hard way this quarter that you should always bus-proof your projects. The project I was working on this quarter had a bus factor of 1. Can you guess what happened? *dramatic pause* He got hit by a bus. OK, so he didn't really get hit by a bus but he wasn't able to work on the project anymore or even help us out with any questions we had.

After he got hit by the bus we were basically SOL after that.

Although the project ended up being a complete disaster, I did learn something from this experience. I found that there are a couple of different ways that you can help to bus-proof your project

Always comment your code.
If your code isn't commented then the next set of developers behind you will have no clue what you were trying to do. Always comment anything that you had to hack around or make a decision on why you wrote the code the way you did. This way no one has to guess your intentions in the code.

Document your decisions
You are going to make many design decisions in your project that isn't going to end up as a comment in some source code.It makes life much easier if you just document why you decided to use pattern x over pattern y or why you chose to use Guice over Spring. You get the idea.

Have a roadmap
One thing that I have found is very useful to a project that is going to be around for any amount of time is the roadmap. By documenting what you plan on doing with the project and give it direction, it is much easier for new developers to see where you have been and where you are going.

Limit the scope of your work
One of the easiest ways to give your project a bus factor is to allow one person to have their hands in the whole project. It is easy to see why this is a problem because if only one person has a grasp of the whole project Murphy's Law is going to take its toll. There are a couple of solutions I see to this problem though. First you have more than one person with an intimate knowledge of the project and second... DOCUMENT YOUR PROJECT. (See the tips above)

As you can see, these are just a couple of ways you can help bus-proof your project. As a good programmer you should always be looking for different ways to keep the project's bus factor down. I definitely learned the value of keeping the bus-factor down at the end of this quarter.

SCP Fun

Just a little thing I found out. To copy a directory with SCP just use the -r flag. (r for recursive duh!)