In-house projects
From OpenEGov
Contents |
Introduction
Normally small-scale in-house projects would stay just that - in-house. The result can be an application that remains poorly documented, suffers from bit-rot over the years as it is gradually hacked and adapted, and ends up as a block on system upgrades and migrations. The alternative is to try to build such projects into the free software cycle, using a version of the following principles:
- Never build an in-house project if there is an appropriate piece of free software already in existence
- All in-house projects should be written and documented as if others were about to read them and judge you on them
- Testing should be built in from the beginning
- Agile programming techniques work well and may be appropriate
- The resulting software should be placed under a free licence
- External users should be able to access the software. It may even be appropriate to build a community around it.
1. Use existing software
initial writing in progress from here on
The whole point of using free software is tied up with reusability. There is every advantage in building on work that has gone before. If you can find a project that does nearly (but not quite) what you need, you may be able to feed your changes back to the program maintainer and have him/her carry on supporting the program for you!
2. Use documentation standards
An internal project used by one or two developers is often not documented; it's 'in their heads'. But if this is going to be free software, it needs to be easily understandable. Part of that is documentation. Many languages make this easy: if using perl, use pod. If java, use javadoc. But if using a language that doesn't include its own documentation system, decide on what to do about it - don't just ignore the problem.
Literal documentation is just one part of the problem. Making the code itself easy to read is another. Baroque class structures are probably not a good idea; a modular structure with a clean API for modules is.
3. Testing comes first
Test-driven development is fashionable. It also produces robust software which can be easily passed on to others for development, since it comes with regression tests from the beginning. Free software development is intimately connected with test driven development: the Test::More and other perl modules have made test packages a standard for CPAN modules, and junit is now universally accepted as the Java test standard.
4. Investigate methodologies
Is Agile development suitable? Even if switching wholesale to Extreme Programming is too much of a culture shock - convincing both managers and programmers of the benefits of pair programming can be hard - there are benefits in changing practices if a change process is under way in any case. Refactoring, for example, fits very well with test driven development and is supported by open source IDEs such as Eclipse.
5. License as free software
6. Let others use it
Benefits
The goal of this process is to generate software which is not only fit for its purpose but which stays fit. Even if there is no external community around it, a good standard of documentation means that new programmers can pick it up without problems. Building in testing from the beginning makes regression testing in the future simple, simplifying the change process. Use of standards keeps the software from being a block on system upgrades. And if the software does generate enough external interest to pick up users, it is likely that a significant part of the testing and development load for the future will be lifted.
