The now regular mid-week meeting with my supervisor convinced me to make some decisions. I’ve been heavily influenced in the past about the use of agile development methods as outlined in a book called Lean Software Development . One of the key ideas is on the subject of when to take decisions. The great fallacy of early software development processes had been the idea that a design was created and then developed with few alterations. This idea assumed all decisions could be made up-front. However if this restriction is removed, it is necessary to avoid the opposite situation of having a decision made by default. Neither is a good. The art form is taking a decision at the most opportune time, i.e. where there is still a choice of directions and sufficient time has passed to make an informed decision. Typically, I tend to leave decisions to later in order to best assess the situation. However, the discussion with my supervisor led to emphasising the elements required for the prototype.
Up until this point, I had been focussing on those core elements required for a fully working application in beta form. It is not my instinct to leave a job unfinished and thus the concept of prototype showing only the required features does go a little against the grain. However I had also been pushing for sound basis and encompassing original thinking into the end product. The approach taken previously has therefore provided a basis of what is possible but now is the time to split out the requirements list into the possible, new and required against those which would have to wait for a fully fledged application. As the survey is now done and dusted, the justification should not be hard to find.
The issue with agile development methods is that they focus on end product and not on creating a mountain of documentation. However, only the report is marked. Not the end result. The actual implementation is merely a means to an end: the theory is that good software development has already been taught. Many individual projects are based on producing good solid implementations and can receive high marks. However, since I have a background in software development which predates university, this would be reiterating a point and there has been an emphasis on breaking some new ground. Proof that this University produces good graduates can be seen in how many of my fellow students are very competent at cutting code on demand. I allowed myself a wry smile when my supervisor suggested a focus on the prototype even though I have a fair bit of experience in software development. Around here, that’s not saying much.
As a random aside, I went to see my folks yesterday and my father asked if I’d gone out Friday night. I responded that I had done so, but it was more like drinks with mates after work than a heavy night out. I actually struggle to remember the last time I went out and came back about 4 in the morning. In truth, I was never much for staying out all night anyway, but it seems to be catching. This is not to say it is all work as congratulation must be extended to Sam Weston for getting his bike licence after more than a few weather related set-backs in getting the first part out of the way. Just in time for the sunshine.
 Ashley Browning: housemate and workaholic. One of the bods behind SotonBus. Basically if you have an iPhone, iPod Touch or iPad and live in Southampton, you need SotonBus in your life. Really.
 God knows why I’m talking Football. Tis far too depressing. The mighty Gas – a.k.a. Bristol Rovers FC – are one point off the bottom of the League One. Not a happy season in BS7. However, miracles can happen.
 M. Poppendieck and T. Poppendieck, Lean Software Development: An Agile Toolkit. Addison-Wesley Professional, 2003.