At the organisation where I am a software engineer, discussions and debates about software development methodologies and tools (such as UML, Agile, XP etc) has gone on for a long time. There is a general feeling that these are a Good Idea, and that we should embrace them, but variety and complexity seem to be big barriers to actually implementing them for real and changing the way we do things.
A large amount of the software development work done by our organisation is accurately described by the term ‘Cowboy Coding‘. This sounds like what we do is shoot first and ask questions later, i.e. we jump straight into things with no planning and hope it all turns out for the best. And in some ways, this is exactly what we do. However, in many cases specific to small academic projects, this approach gets the best results – see my post from yesterday, ‘When Java goes wrong‘ for an example.
The point is that the engineering development model used must be matched to the resources available and the scope of the intended goals. In all the hype surrounding the latest fancy model, it must never be forgotten that a single programmer (or perhaps two), working on their own, and making all the decisions themselves (without any ‘management’) can very often produce working applications that deliver goals in a very short time.
If deadlines slip in this scenario, the first instinct is sometimes to employ more programmers, a solution that is surprisingly likely to fail, for reasons that were first spelled out many years ago in the influential book ‘The Mythical Man-Month‘.
The answer is to match anticipated deadlines to rapid development of prototypes and speedy user feedback at the start of a project, not at the end.
It’s a fact of life that the stakeholders in a software project don’t really know what they want, and can’t even begin to work this out until they see an interface in their web browsers with buttons, text, form fields and images. So it’s important that very basic prototype demonstrators are presented to them very quickly, so that the concrete functionality of the project can be ironed out at the start of the project, not argued about at the end.
This ‘rapid prototyping’ is one of the great strengths of Cowboy Coding and has worked for me many times in the past; its effectiveness should not be sneered at.