Sprinting to the finish.

Back on track a bit more this post.

Just basically had to ditch a load of old software development processes - mainly because of the growth in number of documents and variations on what to do for different computing environments was out of control. Out of control to the point where it was difficult for new entrants into the document set to understand where to start. Best option was to just start again!

Things have moved on as well - as noted in previous posts - agile developments are the current flavour. To be honest this is the approach most people take to software development too - apart from some very expensive military type developments or safety critical applications that is where you may just want to be a bit more rigorous! But for general use most people just want to get on and start coding and an agile process lets you do this in a sort of controlled environment.

This is also the problem faced by engineering projects who's aim is not code development but rather to solve some engineering problem, explosion effects, fire impacts, evacuation implications etc. The problem is most of the time getting to the answer takes a bit of coding - not everything can be worked out by pencil and paper these days. So what are the options? Do some structured programming design following software engineering standards or jump onto something like Excel and start bashing away! Well you know the answer to that one don't you. Plus add a few Macros and Bob's your aunt you have created the monster. An answer to the engineering question pops out, you write the report, and 'file' the code.

And who can blame someone wanting to do that - we are generally paid for getting the answer not for building some shiny new software code. So, the trick is to integrate a development lifecycle into this very results delivery focussed environment. Enter the agile computing frameworks - using some of the techniques from previous posts like Just Good Enough, and Test Driven Design around project timescale based Sprint's - a level of software quality assurance rigour can be injected into the delivery without the 'developer' actually realising!

How do you do this ..... more later.