Interacting with clients using project management systems

If this is a project you finish in an evening, there is no need for a project management.

If, on the other hand, you are dealing with medium or large scale project, project management is strongly recommended for both commercial and personal projects. Unless you do those personal projects just to write code, with no intent to finish them one day.

If you don't use project management for a personal project, how do you:

• track what was done and what you must do (and it is not unusual to not having too much time for personal projects for months, so when you rediscover your projects four months later, chances are you don't remember anything about it),

• track bugs (if you care about bugs),

• collect requirements (because there are few chances to succeed if you start writing code without thinking about what will be the final result),

• etc.?

This being said, you don't have to use every feature of project management.

For example, usually, I never deal with time management on my personal projects. If the project is finished in two months, well, I'm happy. If instead I work on it for three years because meanwhile, there were a lot of requests for commercial products by our customers, I don't really care, since I don't have a deadline and don't lose any money if I finish the project a few years later.

Actually, I would suggest that you do not need a branching model, but rather a complete comprehensive approach to deal with the multi-dimensional constraints with regard to the system without branching. In practice, I believe it will always be a problem to maintain multiple systems that have some commonalities but will evolve differently in branches, so it is better to turn everything into a single system that will evolve as a whole, but consists of different configurations. This may appear to be too simplistic, but there is extensive research in this area, with a lot of successful industrial applications.

The name for this approach is Software Product Lines or sometimes Product Line Engineering. From CMU SEI's Software Product Lines page:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

The key idea is that every requirement, every milestone, every feature (a key term in this domain) is part of the complete system at the highest level. The actual systems deployed at various customers is essentially a collection of features. Each feature however is not just a physical component mashed into the system, it is defined as depending on or enabled by other features (so that by picking a feature, you may automatically include its dependencies, etc.)

Instead then of maintaining all these branches, you end up maintaining one system along with a set of customer-specific configurations.

It may be difficult or even impossible in practice to migrate to such an approach with a very large system, but even then it will be useful to investigate the approaches used in SPL in order to assess what approaches used there can at least be (partially) integrated in your work.

Some additional useful links:

• Wikipedia: Product Line Engineering
• Case Studies by CMU SEI
• Software Product Lines, a site with a lot of introductory material.