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!)

Automate This - What to Automate

Automation

Automate This! is a series of posts about my interest in software development, automation. I'm going to start off by talking about what you can automate and what should be automated on software development projects. Since automation can be useful in more than just software development, you can rest assured I'll rant about anything else you can automate in later posts. But, enough of that little side note, lets get back to what I was talking about, automation. I want you to think back about the projects you have been on. I know it can be scary to think about some of the things you have worked on, but just keep thinking.... OK, now that you have a few projects in mind, how many of them had automated some aspect of the project. The build perhaps, and unit tests (if you actually have unit
tests!) probably are the first things that come to mind, but is there anything else your project automated? If you have had the experience I've had so far, then that is probably about all that comes to your mind.

Where to now?

So where do we go from there? What else can be automated? Is automation really that useful? I know when I first started getting into automation, these were some of the first questions that came to my mind. To answer your questions, yes, automation really is that important. Who really wants to have to remember to run the test suite, or start the build before you leave work? I know I don't, doing those by hand is very error prone. Not to mention the fact that if I had to remember to run the tests, they never would be run! As for what else can be automated, that one depends on what your project needs to have done in a consistent, repeatable manner. Making sure documentation is updated and packaged is a great process to automate, deploying your application is another great automation task. Do you have any code that is generated? Automate it!

As you can see, there really are many tasks in a project that can be automated. Since each project is different, you are going to have changing needs for what you automate. To deal with the changes from project to project, I keep a simple guideline as to what should be automated on any project I work on. If it needs to be repeated, generated, and done consistently, it should be automated.

Some Things Should Always Be Automated

Otherwise, it's really up to you on what you can and can't automate on a project. Although you may have varying aspects of your project to automate, I have found there usually is a core set of things that you should always automate
in a project. My list is pretty short, so read it

Code Generation - Anything that needs to be generated (SQL Scripts,
Web Service Skeletons, etc...)
Tests - Any tests you have, Unit, Regression, Integration, etc...
Documentation - BOTH Developer Documentation (such as Javadocs) AND
User Documentation
Builds - I don't care what you use, just automate it!
Packaging and Deployment - Usually an extension of the build, you
should automate putting the project together as you would release it to the public. If its a web application, learn how to automate its deployment to the web server and you will
thank yourself later.

Go Forth and Learn

OK, well now that we have our introduction to project automation, go out and learn more about it! Look through other projects code and learn how they handle automation and definitely learn how to use a build tool such as Ant, the ubiquitous Make, or the trendy Rake. In my next post, I'll introduce you to these three build tools and show how they are used on different projects. Until then, have fun learning your build system!

Sam

The Pragmatic Programmer

I just recently picked up a copy of The Pragmatic Programmer: From Journeyman to Master and I must say that the book is awesome. This book has easily become one of the most important books that I have read since I started attending Neumont. If you haven't read this book and you are in software development, do yourself a favor and go buy this book right now. The book directly addresses the problems many developers face early on in their careers.

OK, so now you are wondering whats the big deal, right?
right.

There are many reasons why I think this book is such a big deal. This book is written to help you grow as a developer and as a team member, not to solve a technical problem. This book isn't a solution to that pesky EJB bug you are having, or how the Proxy pattern can help your project. Instead it focuses on the facets of programming and working on a team, from learning how an editor and version control, to documentation, testing automation, and pragmatic teams. These are just a few of the sections in The Pragmatic Programmer, once I read the book again I plan on writing a more in-depth review. In closing, go out and read the book now. It will change your way of thinking drastically.

Cheers,
Sam