How software developers use their time: Nozza’s 6 of 8 rule

It’s 7.30pm and I’m back at work after a most delicious Chicken Tandoori cooked by my friends (who took pity on me since this week I am wife and childless).  So what have I accomplished today.   Looking at Process Dashboard (a time and estimate tracking tool based around to the Personal Software Process), I discover 4 hours and 30 minutes of development time; all of it spent on design docs for a new customer.

So what happened to the rest of the day?

Well, I fluffed around with my new cellphone, the Motorola L7.  I’m a Nokia man by preference so it was exciting to experience a Motorola interface and see what it could do.  This took a bit of time, especially as my SIM card just wasn’t being recognised until I tried for the umpteenth + 1 time.

I spent some time working with Steven, helping him with a few technical problems he encountered and a little bit more time for mentoring.  Getting him to figure out what it was best to return from a method called by a BackingBean in JSF.  Most of you are lost at this point but for my fine developer audience, it went something like:

Which is better to return from a method called by a backing bean?  A JDBC ResultSet, RowSet, Array or List? (Hint: there is no ‘right’ or ‘wrong’ answer – I was just looking for him understanding JDBC mechanisms and explaining some design tradeoffs).

I spent some time discussing with a Director of one of the other companies I’m involved with about a new prospect in Christchurch which has warehouses in Auckland, Hamilton and Wellington as well.  So far they seem to be a good prospect for a reference site for our product.

By the time you add cups of coffee, tea, warm milk and pikelets (just joking; I’m not that decrepit), a call from the wee wifey and sending off yet another telemarketer, answering the latest Business Confidence Survey from the Chamber of Commerce, the hours are all up.

I have a rule of thumb about people who are developers and developers only (unlike me wearing all sorts of hats).  Given an 8 hour working period, expect 6 hours to be spend in advancing the assignmentthey are working on.  This little rule of mine is based simply on highly unscientifically observed and anecdotal evidence so don’t bring out the jury yet.  But it allows for situations like:

• Joe Developer gets stuck on some absolutely mind-fizzling bug that JUST SHOULDN’T BE HAPPENING.  Joe decides that before he boils his head in frustration, he’ll ask Jim to look over it.  So Jim isn’t advancing the product with his hours spent.  If he and Joe spend an hour on it that’s two hours of effort, one of which Jim can’t mark down as having worked on his assignment.
• Felix the Frenzied Lead Developer finishes a code review and feverishly finds a teaching opportunity to his new dev on the team.  Felix spends the next 1/2 hour with the dev going over various ways of writing construction tests involving XML files, databases, multiple-threads, GUI’s and some esoteric domain-specific language.
• Sean the syphalitic senior developer gets a call from his aunt’s friends bridge-partners niece trying to get tips on how to score a graduate job at some random cubicle-loving, PHP-spawning, code-monkey dancing software house.
• Mergatroid the Maniac Project Manager insists of using the latest buzz-words and learns about ’sit-down’ meetings.  The latest gimmick in Project Management to avoid all the pitfalls of ’stand-up meetings’.  She rigorously applies a minimum meeting time of 45 minutes per week.
• Leisure Suit Larry is encouraged to spend 4 hours per week up-skilling, learning and improving his development skills.  Today he discovers a dusty old document in the work library entitled Risk Themes Discovered Through Architecture Evaluation; A Risk-based Approach to Quality Assurance of Architectures and spends a hour and three coffee’s with it.

At the end of the day, these guys aren’t (or shouldn’t be) code monkeys that we can command like huskies.  Neither is the nature of the work they are engaged in a sweat-effort.  My suspicion is however that there are a number of enterprises out there that attempt to manage so:  Mush; work faster; work harder; dance; heel; more lines of code damn you! Perhaps such managers would feel better if they learned Nozza’s 6 hours out of every 8 rule.

Cognative behaviour and the Ops Manual

It’s Saturday.  I’ve driven my family and I to Moronsville (see the map) to go to the in-laws where food is plentiful and wonderful.  It’s always relaxing and enjoyable.  Erin’s parents are nice folks and they have a quiet peaceful large section which little Charlotte loves to play in.

But no time for tranquility to rule – the machinations of the empire work on!  I’ve worked on architecture and high level design for a customers project, and refined the section in our Ops Manual about hiring.  No longer do we look for “suitable intelligence” but “suitable cognative behaviour”.  For no other reason than I enjoyed using the new phrase more.  It inspires me to think of some PC terms:

• You lack cognative behaviour – you’re as stupid as a pudding
• You display cognative dissonance - you damned hypocrite.

Enough frivolity.  I’m a firm believer in our Ops Manual.  More correctly, I’m a firm believer in having systems, procedures.  Some people think that you can’t turn a software shop into McDonalds and I agree but that doesn’t mean you ignore published systems and procedures and guidelines altogher.  In our Ops Manual we have a hiring section so that we learn from the past and so our hiring success is repeatable.  If I get run over by a bus, someone else (probably John or Mark) has something to go on.  If I forget how to spot potential and talent, I can remind myself (is there irony in that?). 

 Anyway, more on the Ops Manual later on.  In the meantime, I’ll refer you to the E-Myth Revisted by Michael Gerber for more infomation on how vital it is to have repeatable systems and procedures.

Business Advisory Board

I’m setting up a board of two consultants to advise me on topics such as:

• marketing, market analysis and appraisal
• software licencing and pricing issues
• b2b sales and partnering
• exporting and commercialisation of product
• strategy
• etc..

The tenure is for one year and these are paid positions. Hopefully the members (other than me) will have all the fun of telling people (aka – me what to do without having any authority or legal ramifications if something goes horribly wrong. And get paid for it!

There’s details on the site, but you’d have to find it first, so email or comment if you know someone who’d be interested who is in good ol’ NZ.

It’s a bit of a case study where I am because as far as I can find out there are not too many of these beasts around (advisory boards that is not consultants – there are plenty plenty of those). So I’ll figure out things like what to pay, what to expect, what contract clauses are good or bad, do we have eggs benedict at breakfast or overcooked coffee in the afternoon, and all manner of world important things.