Project management — the tire swing

I randomly found this picture yesterday and it really describes how things are going in the group project I am involved in.

You leave the discussions from the last day thinking “Everything is all sorted, and I know how we are going to implement things.” The next day the discussion revolves around the same task after someone suggests an alternate method, yet there was nothing wrong with the first method, in fact both methods are of equal merit. However the group discusses the same thing again and again, and I just want to get round to coding the damn thing.

I’ve ended up just writing the code myself, based on one of the numerous choices, screw discussing it further we have a deadline to meet! All that matters to me now is getting the input and the output working as they should; once the program is up and running then — and only then — should we worry about refining it with more efficient methods of doing components. For example in multi threading we could use manual locks, shifting synchronized methods into their own classes, volatile methods, and so on; they all do the same thing in different ways, lets just use one, or even go for a Taguchi methodology and try two, in a prototype and see how things go. I’d rather spend my time working on a few simple prototypes (that can be utilised for the final build) that highlight the problems than spending the same time (or even longer) discussing which is best…

This post is going on for too long, rant over…

Sometimes Google Adsense can’t read

Sorry about the lack of J2ME…

Netbeans 6.1 looks to be another fine product