Programming Playground Rules

The Lab Team (Dan, Peter, Anurag) met this afternoon to discuss some development methodology as we begin to develop more code and scripts to support the PoC Projects. The idea is to stay agile and lightweight enough to continue the rate of innovation, but to add some consistency that will make it easier to scale.

Some recommendations that we've made and decided to follow are:

• Use Sourceforge Subversion site to store changes - All changes are checked into the Subversion site on the sourceforge project. Only security related changes (passwords, etc) are not checked in, and these are factored out into a property or configuration file.


• Everything builds - Maven is used to build (compile and package) and deploy changes. This will allow for changes to be made on different desktops without spending time trying to manually configure a new environment. This also means that if the build breaks then the developer who broke it needs to fix it as soon as possible.


• Follow the Sun Code Conventions for Java. These are old, but still applicable for what we're trying to do. We picked this sort of as a default and this can change based on feedback and practice, but we want some uniform style to the project.


• Document code- document code to improve clarity. Use javadocs where necessary. This is not documentation for documentation's sake, but enough so that someone coming across the code will be able to follow. This doesn't absolve a programmer from clean, concise coding but should improve on the clarity of a source file.


• Write a Use Case first- the first step to development should be to make a post on this blog describing the use case. Nothing too formal, just a description of the steps, who will perform them, alternate flows and error handing. This will provide a way to capture the requirements before any code is written.


• Next write a Test Case before coding- after the use case is posted and there's some sort of agreement, then a test case is written while the coding is performed. This speeds up development by institutionalizing testing in a standard manner.


• Each project will have a separate folder in the sourceforge root with a Maven pom.xml file for the build (including dependencies).

We'll add/subtract to this list as we get going. Once we're confortable with them, we can put them in a proper document and link to them from the left navigation bar.