November 11th, 2007
In our opinion the best software development method is called ‘agile development’.Three elements are key:
- work iteratively (preferably in small chunks)
- have it working all the time
- work together
A definition: ‘agile methods emphasize on building releasable software in short time periods, and work is performed in a highly collaborative manner’. This is good: have something working and everybody knows what is being made.
I will not elaborate on this too much, a good introduction can be found on the web or in various books.
A small note: one can, of course, take this as a plan and follow ‘the method’. This we have seen not to work very well: methods are guidelines not recipes.
ToolsIn order to do this one needs tools, the right tools! You will need:
- a collaboration tool (for sharing design, documentation, bug tracking etc)
- a build environment
- standard building blocks
CollaborationSimplicity is best.
Build environmentThe Visual Studio IDE is not really an agile tool: sharing the environment is hard, it will not (or with much difficulty) allow for unit-testing, it cannot modularize components (dlls/libs/exes) easily and blurs the structure of a piece of software by overlaying the filesystem with its own layout: in short, it will not help, but only confuse developers.
It is simply not cut out for large, co-operative software development (not to mention vendor lock-in and versioning).
The Visual Studio C++ compiler/debugger, however, is very good – no argument there.
There are much better tools: ANT, Bjam, Makefiles (or even better, makefile generators) and others. These are portable, textbased tools anyone on any platform can use without difficulty. Searching becomes easy, structure is visible.
Bjam is the tool of choice of www.boost.org, and it is easy to see why: it is portable, supports unit-testing very well and follows the layout of the software.
Unit testingA lot can be said about this. Without unit-testing no piece of software will ever be reliable. It is that simple. Why? Without it you will never prove a piece of software works, and you will never have regressions. As things grow larger, you need regressions to make certain components work and keep working as expected.
To do this without hassle, use a tool that runs unit-tests automatically and build your continous build on top of it: bjam is exactly this tool – we should use it too, it’s not that hard and the benefits are numerous.
ComponentsUse the standard components! They are standard for a reason, do not roll your own. There is a 99% chance the standard will do better, since is is created by all the experts in the field at hand.
Nowadays, standard – or almost standard (TR1/2) components are available for almost anything: networking, threads, serializationi, parsing, databases, graphics. Use them!
Use standard design patterns and paradigms as well: one of the least known is the ‘c++ destructor model’ – or RAII (‘resource aqcuisition is initialization’, see Bjarne Stroustrup). Simply put: use the smart pointer! The C++ language guarantees you it will work.
SummaryIn short, to ‘get the job done’:
- collaboration: trac/subversion
- build-tool: bjam
- unit-testing: boost-unittest
- components: STL, Boost, OTL, ...
- communication: mailinglist
- continuous build: cerberus (or bitten, or …)
- continuous/regression test: custom (but boost.regression can be a good start)
Note: good points can be taken from the pragmatic progammer starting kit