Development Standards and Principles

Brad's AMoRe presentation on 2009.09.17 on the paper below is timely, for me at least, because in the previous week I started putting together some thoughts on how best to structure a SVN repositories for new projects within PSM. This is one aspect of the overall structure which the paper advocates as contributing toward the ideal of reproducible research. This overall structure can be represented as a set of written and living design standards and principles documents.

• Matlab blog on reproducible research
• Reproducible Research paper

In order to develop products whose utility will continue after the developer has stopped working on that product, it is desirable to make the code for that product as understandable to others as possible. This is even more important when multiple people are working on a project and their development efforts must be compatible with each others'. This has led to the development of written standards that describe some characteristics that projects should have. These standards could take several forms, as appropriate for the environment, and could refer to (possibly language-specific) styles of software development ("coding standards"), project and file structure, documentation, etc. Many books have been written on this subject.

Every industrial environment in which I've worked has at some point entertained, developed, and/or enforced the notion of coding standards, because every such environment has had multiple developers who want to create products and code that are as usable as possible. Some aspects of the PSM lab are already more structured than one might expect of an academic environment, such as the use of lab notebooks, the fairly well-developed PSM software inventory, MDA, and our collection of SVN repositories. However, it's always useful I think to develop other standards as appropriate. Especially if in the development of something, you find yourself wondering how to structure something. The result you come up with should be written down so that it can be considered by others in the lab and modified as appropriate, and so that as it is adopted by others, the overall understandability of projects in the lab to others in the lab can be increased.

Sometimes you don't really get an understanding of how to structure something until you've tried to structure something and run into some of the limitations of your solution. This has been the case with the previous projects (HDRAmbLightPaper and Mesopic) whose SVN repositories I've started. In doing those, I've put together a list of what I think are some good SVN repository design principles. This document should be updated as we decide to add other principles or change any of these...

• How to structure a project's SVN repository

-- AllanRempel - 09 Sep 2009