I’ve been searching for the perfect set of tools for software development. I am searching for the kind of workflow where there is no workflow. It just happens – coding like water grasshopper.

I’ve become disenchanted with most of the tools I’ve used in the past. The tools almost always seem to get in the way of getting work done, and I figure when you have to do work in order to do work, there is a problem somewhere.

This is my ninja setup; the get it done setup.

There are several reasons I think this is a very productive setup for small teams, but the biggest reason is probably the fact that everything is in the repository, and everything is editable with a text editor. I’ll list the pros and cons after the tools, but I think the tool descriptions will speak for themselves.

Git

The whole workflow centers around the version control system Git. I am not going to try to convince you that git is awesome (there are many sites that can do that better than I can), but I personally wouldn’t start another personal project using anything other than a distributed version control system anymore. I tend to like git because the branching and merging are second to none. I also dig the fact you can just basically throw it on a server to share the repo.

Ticgit

Ticgit is the ticketing / issue tracking system in the ninja setup. The reason this is helpful is the ticket system lives in the git repository. So where the repo goes, so goes the tickets.

Every branch and tag also contain the ticket for the project so you have full project snap shots at all times. A tag also tags all the tickets. When someone checks out the code, they get the whole ticketing system along side the code. Ticgit uses a simple command line interface, and your usual editor to enter and edit bugs so you don’t have to fumble about with some overly complicated external interface.

Sphinx

Sphinx is used to do documentation. It sits inside the repo and is made up of easy to use, easy to update text files. Which are, again, editable in any text editor. No need to log into a wiki or update some RTF document – you just type the text. The markup syntax of Sphinx is similar to wiki or markdown syntax so it’s more or less completely natural to any developer.

Since Sphinx documents are simply text files, they live in the repo right next to the code and the ticketing system. They go along with every branch or tag as well and inherit the benefits of branching, merging and patches.

Org Mode

Org mode is, at it’s base, a file format used to do outlines and TODOs. However, it also supports tagging, metadata, dates, and it functions as a wonderful project management system. (I’ve been using it for quite a while as my GTD system).

Since org mode files are also just text files, they can live along side the code as well. They can be versioned, tagged, merged, and distributed right along with the code, and the format of the file is trivial to learn.

Gitweb

Sometimes it is helpful to have a browser based version of the repository. Gitweb provides a web interface for git (with a bit of setup). You can also use gitweb to do RSS feeds of pushes (commits) to the master git repository. This piece is not completely needed, but I find it nice to have.

Here are the benefits to my ninja setup:

1. Everything is with the code – tickets, documentation, project management and has all the benifits git offers.
2. Works on any system pretty much anywhere – GUI or not.
3. Allows moving to a more complicated system since all the files are machine parse-able text files
4. All the tools are free, and use open formats
5. Easy to use – if you can use a text editor you are golden
6. Easy to learn (that’s subjective obviously. If you’ve never used a shell or the command line it might not be so simple)
7. Highly scriptable / tweak-able
8. Fully usable offline without an internet connection. You can do anything while on an airplane.

Some drawbacks:

1. Time is not a factor. If you are into hourly tracking there isn’t an easy way to track that in this system.
2. Only developers are likely able to use the system. There is no way for a client to directly submit a bug for example.
3. Learning curve (as with anything)
4. Probably quite a bit of setup on Windows. Trivial setup on Linux and Mac, but on Windows it is a bit more complicated.

So far that’s what I am using. It’s been serving me well for a few of my smaller personal projects, but I’ve started using it on a larger project with more developers. We’ll see how it goes, but I anticipate it working very well.