Simple management of personal projects (that scale!)
Managing code, projects – deadlines, tasks, and integration with a team is a tough task. A lot of people, and businesses I feel could be doing this a lot better. It starts with the single person actually, that will change your – and eventually your team’s way of how to manage your “stuff”. I’m a bit torn on putting this only in development – as it’s both development and personal productivity.
Lets begin with the first problem. Source code management – but it’s not only source code that needs managing! Every bit of information that you routinely change can benefit from a management system. Personally I used to use SVN for a lot of stuff. SVN is pretty fantastic in that you can keep a log of your entire development history. Source code management is definitely not only for teams. Every project I have done in the last 3-4 years is versioned, everything I start is versioned and has a specific location and setup associated with it. I’ll get to the structure of projects later. Instead of SVN, I personally now recommend git – and I don’t mean getting a graphical-type app to interface with GIT – I mean, learn it from the command line. GIT is a lot stronger than subversion in my opinion, and has better perks for single developers because creating a project is as simple as going into the directory and typing git-init. I’ll try to provide some resources a bit later.
Now for the next problem, that being documentation. Even for personal projects, it’s very very important to document your code. Why? I can’t tell you how often I go back to code I wrote and wonder why I did it the way I did. A lot of it is growing as a developer, but sometimes there’s a darn good reason why I did it a certain way and in the process of “fixing” what I thought was wrong – I actually create more problems. Every single project, little or large should have some documentation. By my own preference, I begin the documentation phase well before I even write a line of code. I come up with brainstorming charts, flow charts of some ideas, and pages that I reference to learn about what I’m trying to fix. Why not just start coding? I can’t tell people how often I messed up and began coding only to find out a solution existed and was simple enough. Also, when you plan out things ahead of time, you find out that perhaps it’s either more complicated or more simple – and your perspective and plan for what to do changes. For anyone who took the 7-habits training, this is basically the most important stage focused in a lot – instead of just reacting.
Structure is the third really important area. Your code, and documentation need to have “standards” for where they are at. Why? I’m sure the search feature on a computer is fantastic, but knowing where to look is easier than searching. For personal programming projects, I tend to keep the code and the project documentation together. I use the directory structure below:
/code
/documentation
/templates [for django apps]
In the code section is the main project files – this isn’t very language specific – just whatever you code goes here. The documentation is where everything for documentation goes, including documentation generated from code (e.g. pydoc, phpdoc, etc). Templates is also very simple, for all my django apps I use a templates directory to keep my own themes outside the built-in themes of a django app.
What about managing your tasks related to a project? There are a LOT of options available for this. Personally, I find myself using a project called Trac. There’s no real specific reason why I use this except I like the way it is presented, gives me graphs of how far along a project is, timelines, and so on. It also integrates with GIT pretty well, so seeing what changed, GUI style, is super simple (I tend not to use this, but it’s there). There are a number of projects that exist, but I recommend setting up one. The reason why they are helpful is because you can split out your brainstorming and “needed ideas” away from the tasks you’re doing. For example, when I’m coming up with ideas for a project i’ll place them into Trac as “wants” for version 1 (I call them “release 1″, “release 2″, etc – about once a month time). When I begin working on version 1, I put new stuff that aren’t bugs into version 2. When working on version 2, put them into version 3. The general idea is to avoid your own scope creep by realizing that you have your own internal deadlines that you want to make – and adding “hey this will be cool” to it is just going to make the deployment longer.
Well, there you have it, these are the main building blocks that I use to actually get projects completed. Is this a definitive list? Definitely not. I missed a number of fine grain details including the whole general GTD thing (which is outside this). A lot of people may be thinking that this is fairly complicated to follow and doesn’t have much value – but I beg to differ on that. While, in general, you may lose some time at first on projects, in the end you’ll gain better projects. Ideas that you come up with and document will end up in the project, where they may end up being lost because you didn’t note it down. You’ll also get the wonderful joy of seeing these little bars fill up as you get further in your goals. So all this gives a nice self esteem bonus as well. After a bit of time, the whole process will feel like second nature.
Resources:
Trac: http://trac.edgewall.org/
GIT: http://git.or.cz/
GIT from the bottom up (my favorite ebook on this version control system): http://www.newartisans.com/blog_files/git.from.bottom.up.php
