Floyd’s Thoughts…

Yesterday evening i spent a couple of hours sitting in my garden reading while the summer evening sun rained down. It was one of those peaceful moments where time seemed to stand still.

This morning when letting the Dog out to do what ever it is she does first thing in the morning, i took a stroll down the garden to reminisce about the night before only to realize that i had left my IPhone 3G on the hammock.

The sun that had blessed us the night before had been replaced by Rain and the IPhone was soaked! Needless to say, it doesn’t switch on any more and I’m gutted!

Fortunately i still have my old IPhone 2G so i can use that, but every time i look at it, it reminds me of my drowned little baby that was only a few months old

Oh well life goes on, I’ll get the insurance company to send me a new one tomorrow

When your developing, enhancing, evolving your software you will introduce bugs which range from trivial UI issues to “Show Stopping” issue in business logic that will drive your customers away.

Its pretty easy to prioritize these bugs as tasks for your development team by making the “Show Stoppers” #1 priority and so on… and this list of priorities is often geared around the customer, we make sure the issues that the customer will react to the most are sorted out first and then we get to the other “trivial” issues later (if ever).

While this method of prioritization works well in theory I have observed that developers who are not allowed to fix bugs that annoy them or are “easy” to fix, often loose motivation and interest in fixing those bugs that are not so easy to fix.

I have myself worked on projects where the PM has taken exception to me spending an hour to fix and test a bug because I felt that it was worth doing even thought the “Plan” didn’t express this.

Its so important to let your development team cherry pick issues to fix as well as prioritizing the “Show Stoppers”.

Why?

Developers love marking tasks as “Dev Complete”, it gives us a sense of achievement that motivates us to crack on with the next task at hand.

“Wasting” (if your a PM) an hour on a task that isn’t the most pressing one at the time can have a profound impact on your teams productivity, letting the developers mould the shape of the product by picking the issues, tasks to work on gives them a sense of ownership which brings with it a sense of determination to deliver.

I liken this to the Broken Window (Tip 4) theory expressed in The Pragmatic Programmer by Andrew Hunt and David Thomas.

An Investment in knowledge always pays the best interest.

Benjamin Franklin