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.

Hairloss treatment for developers

A technique I’ve found quite useful is the Fishbone diagram. Actually it’s not the diagram that’s useful – it’s just that it forces me to Stop, Think then Act. Many bugs get sorted via the debugger or just plain old desk-checking but some problems are much more perplexing. You know, like when your FormatAllLocalHardDrives routine never seems to be called by your XML-based UI. Or when your app just can’t figure out where that ODBC DSN is.

So the fishbone should come out when it’s past your bed-time and you are still trying to solve the same problem that you started at lunch. Crank fishbones out when your hairloss is due it being torn out and not your spritely age. Use them when you feel as dippy as a doughnut for not solving the problem.

Stop – The end of Quick and Dirty debugging
Of course, the first problem is realising when it’s time to stop and think. Steve McConnell suggests you set a maximum time for this quick and dirty debugging in his book Code Complete. I agree but we all know how time flies when you’re having fun. What could have been a “I’ll stop in 15 minutes” becomes “Holy Potatoes Batman, when did everyone else leave?“. I’m still thinking about this one.

Think then Act
Now you’ve finished your quick and dirty debugging dash, it’s time for a little more cognitive process. Here’s some pointers:

1. Note what you’re trying to achieve. It’s often useful to remember the point of the code in question. Instead of spending the rest of the day debugging this code you wrote in an hour, perhaps there’s a different way of writing it so that this problem isn’t manifested. It may well be better use of your time.
2. List all possible causes for the symptoms. And don’t just skip some because you think “that’ll never be the case” – this is how I ended up writing this post (naw, the log messages aren’t in the file because stderr is redirected somewhere – it’ll never be because my routine isn’t actually called). Be thorough and engage the brain. Writing it down with the old pen and paper is a great aid to this.  Let me repeat that: Writing it down pen and paper will help you.  Yes, it will. So do it!  And I’ll check on you…
3. Make a battle-plan. Prioritise what you’ve written down so you can determine the most-likely to the least-likely causes. Then figure out some tests to see if each cause actually is the cause of the problem.
4. Give battle. Take that sucker bug down! All going well you’ll have found that one of your probable causes was the actual cause. All not going well means that Murphey has found you and you’ve run out of ideas with the bug unfixed. Let’s leave that for another day, shall we?

Industry demand: graduates must know their theory

Today I participated in a focus group organised by IPENZ (Institute of Professional Engineers New Zealand) on the education of new graduates.

I’m not short of a few views on this area so I went along to speak my piece. The message I wanted to bring was Universities should focus on developing fundamental academic knowledge that can be applied in a variety of situations.

Happily, the focus group were all in accord with this and we all had the same reasoning – teach a man to fish, don’t give him one (sic). If you come to Ablaze Software for a job interview; I’ll be looking to see that you understand the core concepts of what you’ve learned and if you can apply those to new and unusual situations.

Last year, Ablaze Software was looking for an intern-developer and out of 42 applicants at 2nd and 3rd stage undergraduate degrees, 7 got interviews. Nearly all of those 7 had taken a paper called COMPSCI 280 Applications Programming from the University of Auckland. The outline for this paper says:

The course offers an introduction to graphical user interfaces, 3-tier architectures, and techniques for integrating applications with databases and the web/Internet.
By the end of the course students who succeed will be competent VB.NET Programmers.

Foolishly I used this information to ask questions to those who passed this paper like:

Me: Tell me what’s different about managed-code compared to non-managed.

Them: Uh,.. managed-code…., I don’t know what you mean

Me: What do you think is important when designing a GUI to interact with humans

Them: Uh, you need to make it look nice.

Me: So how did you integrate your application with database

Them: We used VB.NET. It can do that for you.

Me: I see you did an intro level paper in Java. What’s different about Java and VB.NET

Them: VB.NET has got colour coding.

This will do nothing except plunge our beautiful green country into something akin to Mordor – where we’ll be stoking the fires of Mt Doom. (a little poetic licence is allowed is it not?)

When universities can teach concepts and fundamentals properly, our economy will benefit – that’s what we agreed on in this focus group.

However, our government has set up universities to be much more dependant on the free-market model. “Bum’s on seats” seems to be the cry of the day. Because the more bum’s you have, the more money you get, the more research you can do, the more famous you are, the more staff you can get. Big departments can also afford the niceties of life such as waterproof toilet-paper. So when industry hints that it might be nice to have graduates able to do non-academic things like read and write with some semblance of intelligence then the head of department thinks like this:

Dr No – Head of Department (thinking): eh, what – read and write! Poppycock, they should learn that at school or be canned. Hmm, shouldn’t have abolished canning – did wonders for learning……But wait. Eureka! Reading and Writing 101 will be much easier than some other paper. Ahh, more interest from students. Ahhh (rubs hands) – more money. Now we can get that waterproof toilet-paper. Humpf. What course can it replace – something that no one likes too much and has too many people failing it. Hoo, what about Fundamentals of Concurrent Programming. Yes, we’ll rid ourselves of that.

And then the government of the day congratulates themselves on how well they’ve reformed the tertiary education sector.

I think that Bum’s on seats means exactly that – too many bum’s coming out of universities.

Say this fast 10 times

Cassey casts classes on the classpath

Maturity beats the cutting-edge for productivity

It is the year of our Lord 2006, and I have finally fallen in with the crowd – I’m now blogging and also involved in making web-based applications. I must be trendy

I recently had cause to put in a menu bar on some of the pages. Easy! I had been able to create menu bars for the past 10 years. Ahh – but never had I created one on a web-page. Oh – it’s ok, someone has done a Javascript one for me that’s popular and works. Well then, let’s at it!

I should run a contest for how long it took to get the bloody thing working properly.

2 hours?

4 hours?

7 hours and pi minutes?

Actually it was 10 hours, 9 of which were rather frustrating. Blame it on my incompetence if you will, blame it on my lack of experience with web-apps, blame it on the technology stack of HTTPS, HTML, CSS, XML, Servlets, and JSF but the point is it took me 9 hours longer to create a menu in 2006 than it did in 1996.

And this is totally indicative of my point: For shipping products out the door – mature technologies are the single biggest help (yes, ok, ok besides people)

In 1996, creating menus for Windows and DOS was so common that there were tools that helped you do it in minutes (yes, I am an ex-Visual Basic user). Everyone could create menus and text boxes and display text all so easily on a personal computer because we had been doing it since the year I was born. Productivity was some factor of e better in 1996 than 1976.

Not so for web-based applications because they are still immature, as in teenagers-immature. All the web technologies want to be noticed and suffer from peer-pressure:

WebGirl1: “I use Flex2, and it’s like, so wow”

WebGirl2: “Well, I wouldn’t been seen dead using anything but Ruby on Rails”

WebGirl_2045: “Oh, look at that Java Enterprise girl over there, what a retard”

WebGerlRokz25: “She probably can’t even do PHP5, CSS2 and Javascript”

When we spend more energy today on things that yesterday took little effort, then we know we’re not where we ought to be. And yes, I know that stateless HTTP wasn’t designed for what we’re doing and that distributed computing has always been a challange, and wah, wah.

But accept the fact that it may just be better to abandon all the cool cutting-edge technologies and go with something a little more tried and true. So don’t go out and start your next big-selling application in Lisp or using Ajax2.1, or MyNewStrutsFramework 0.1. Let the other companies loose money on it first