4 Things to Do Before Starting a New Project

Are you ready to put your hands on the keyboard?
(Image by courtesy of +Riccardo Esposito)

This is the situation: the Project Manager has written the specifications, everything is clear and you only have to do the kick start to you team of developers.

This point is where you can start to fail. If you let every programmer (that is lazy by definition) to take its own decisions, your project will be pure anarchy.

Here there is a short list of things to consider before starting to write code to have some chance to do the job in an acceptable amount of time and without losing your mental health.

1. Select a VCS and Lay Down the Rules for Commits and Branches

I suggest you to use Git. I have already explained the reasons in this post but, to make it short, Git is fast, cheap (not because it's free but in terms of disk usage) and extremely powerful.

Once you have chosen Git ;-) you have to set clear rules for commit and branches to avoid developers transform your repository in a landfill. You can take inspiration from this great post.

The rules should also cover commit comments because it's important that every change in the repository is correctly documented.

2. Define Coding Styles

Using the same code style is very important if many developers are working on the same project. Everyone should be able to understand and modify every piece of code without spending time to feel comfortable with indentation and names.

To improve the adoption of a style, you can institute a fine of 1 euro/dollar/pound for every line of code that is not correctly formatted and, from time to time, use those money to go to eat a pizza all together. If you are wondering how you can detect the author of each line of code, git blame is the answer.

3. Define the Style for the Technical Documentation

Every function should be preceded by a comment and Doxygen is a wonderful tool to collect all those comments and generate a document or a website for a quick reference.

Obviously not everything can be specified in a comment into source files. To write documents that can be easily managed by a VCS, I suggest Markdown and Multi-Markdown. The idea behind MD is to have an easy-to-write language to create HTML snippets that is also easy-to-read while MMD adds some features (such as tables) maintaining the same philosophy.

If you prefer a WYSIWYG editor, you can save your documents in odt format and use odt2txt in order to let Git show the differences between revisions; here is how to do (unfortunately this works only for diffing, merge is not allowed).

4. Chose a Decent Bug Tracker

Maybe now you are asking why is important to choose a BT before having written a single line of code. There are three main reasons:

first, you can use it also to assign development tasks,
second, soon there will be the need to change something in the original architecture; use the bug tracker host the discussions, and
third, don't let the Quality Assurance team choose for you ;-)

Speaking about bug tracking tools, I would like to tell you how much Redmine is great but unfortunately I've not (yet) had the opportunity to test it. In my company we're using Mantis and I can say that it's not so bad for medium-size projects.

Remember You Are Not Alone

All the above points are useless if they are not agreed by the development team. For this reason, rules should not be imposed from the top but discussed with everyone is involved in the project to make sure they understand the logic behind them.

It's important to keep an open mind in this phase because developers can suggest some improvement, based on their experience, to better adapt those rules to the specific project and the team.

OK, now you are ready for the kick start. Good luck!