This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. The first article in the series was If you don't know why you're doing it, you shouldn't be doing it.

When I first set out to build Gitano, I knew that I was doing it because I missed the ease with which I could publish bzr repositories on a server and I'd looked at Gitolite and knew I didn't want to use that. I'd taken one look at Github and discounted that too. But I didn't start with a plan for how to achieve any of this. Indeed I started with a name which ended up being taken by another project well before I was ready to release, meaning I had to rename my project before I'd even made one release.

Being a seasoned hacker I immediately started down a path of yak shaving by writing some utility code I'd need to let me interact with Git repositories from the language I'd chosen to implement Gitano in, without any kind of cohesive plan of what such a beast would look like, or work like. It took me a long time to dig my way back out of that hole. Eventually I made a plan for what I'd need to achieve a minimum viable product for myself and that really focussed me toward the right path.

As with reasons for writing things, plans don't have to be fully formed but they do need to be present to prevent you from wandering off the path into places which might seem interesting or useful but often don't help you achieve your goals. A plan can be as nebulous as "I will just hack and see what happens" but if it is, you need to be aware of what that means for how likely you are to achieve your ends in a timely fashion. I strongly recommend that you plan your projects at least at a simple bullet point list kind of level. For Gitano my plan was approximately:

1. Build git abstraction for reading config
2. Add push and pull support over ssh
3. Add admin commands
4. Add gitweb support

Things didn't necessarily go in that order exactly, but all in all, I achieved those basic goals and I had my minimal-viable-product. Naturally I didn't release this, but I did start using it myself. In addition to actions to perform, plans might include architectural decisions such as what language to implement your project in, or tooling decisions associated with the project. Just remember that no plan survives contact with the enemy and as such you should always be prepared to adjust your plan when new information comes to light.

So, here's your homework for this truism: Pick one project you're currently floundering on -- it might be related to open source, or it might simply be something you need to get done around the house. Write down a two or three point plan to achieve your goal and see if that helps you to get there any faster.