I'm not talking about ongoing projects that have multiple versions (e.g. Photoshop, Windows, GCC), I'm talking about projects that have terribly underfunded development. The projects that i am talking about are the pet projects that are too big, and in house projects that are unsigned by publishers so they only get a few man months per year. You know the thing, a project that would have normally take a reasonable amount of time, but due to unforseen (or possibly forseen but ignored) circumstances, has to be put on hold "for a while". This kind of project can dishearten people more than any other, as code begins to rot before the project has finished, or other people bring out new software that is very similar to what you were going to do, or worse, you lose heart, leave the project so long that you forget all the good ideas you had when you first started the project.
So, how do you stop these long projects from crumbling under the weight of time? How can you set a process by which the project can be dropped and continued? What is the essence of a pausable project?
I've worked on quite a few never ending projects, and of them all, only two have been pausable. Both of these projects are connected to each other, which in some sense makes the number of projects just one, but i think of them as two projects, as one is dependent on the other, but not the other way around.
The differences between the pausable pair and all other projects I've worked on seems to boil down to coding style. Not coding style from the point of view of braces and how to name your functions, but more of a "don't hack" attitude. This is an important thing, especially in a project that does not have a design document (another victim of the never ending project's underfunding). I've found that in the pausable projects, there is a distinct truth to most things, there are no lies in function names, classes do what they sound like they do, they all have similar construction, and all have similar style of implementation. There is consistency of implementation, even if there is a shift in thought. There is also a bold line struck between modules of code reducing the coupling to the minimum. This means that the code is easier to search, easier to modify, maintain, and remove if it was never necessary.
So, is the pausable project a better project in general?
Probably not. You pay the price in performance when you make your code extra readable and easily maintainable. You also pay the price in terms of time to develop, as without a thorough design, you may code many more modules than necessary. So, even though the project could be restarted at any point, is easier to maintain, can be reused and can be used to teach good style, the actual code takes more man months to develop, is slower in terms of frame rate or other performance metric, and is probably more bloaty than necessary.
So, if its not better, why do it this way?
Well, not all projects have the benefit of a straight line in development. Not all projects get done at all, and sometimes its better to work on reusable code, just so you can reuse the code on the next endless project. Some projects don't need the performance of a fully designed and tuned project, but do need the maintenance and modifiability of a pausable project (think about converters and editors).
its up to you to decide if your project needs to be pausable, but if it does, keep the following in mind:
- The maintenance programmer is you, and you will remember none of your tricks until its too late, so document them or don't use them at all. Never do anything unexpected, no hacks, no odd code.
- Be strict in style, if you change style, then you lose flow. Stick to the style you started with, or change the style of the entire project so it's still consistent.
- When you make additions and deletions, show your reasoning in comments, otherwise you will forget why you did it, and might change something in error. Also keep the old code (commented out?) so you can see what you deleted and possibly reintroduce it if it was an error to delete it in the first place.