Nerdherding for Beginners

Seth Godin wrote a post in which he is critical of creating things that are good enough. He is saying that good enough is the opposite of the pursuit of better (or as he calls it the relentless pursuit of better).

This is, to borrow a phrase, crazy talk. Good enough is an important stopping point on the way to better. If you don’t stop at good enough then you won’t ever reach better. I think that Seth’s own example of JetBlue turning one third of the toilets on its planes into a ladies only toilet demonstrates this. Did JetBlue delay launching their airline until this epiphany came to them? Clearly they didn’t. They created a package that was better than their competitors which had good enough aspects and great aspects. Coming back to make the good enough bits better is fine but they went with good enough knowing that waiting for better on everything would kill them.

Perhaps a better idea (sorry) is to make sure that at least some aspects of our products/services are better and that the rest are good enough and then made better as soon as is sensible. I wonder if Seth would agree?

Sometimes nerds sneak in unexpected features to the things they create. I’m not talking about easter-eggs but features they believe will be of value to the product’s users. This is a bad thing to do which is often a surprise to the offending nerds. Its good to be proactive and to offer additional low-cost features to customers but adding them without checking first is imprudent.

Most of the time the nerd who inserts the unexpected feature isn’t the customer (or the customer’s representative). So why is it okay to spend someone else’s money on something they might not want? Maybe they would have wanted something else instead. Maybe they would have preferred the software to cost a bit less.

There is also an additional cost for every feature exposed to those who use software. Someone needs to explain the feature, it needs to be tested, maintained, and so on. So even if the feature truly didn’t cost anything to implement (say it was autogenerated by an existing application framework) then someone’s money has still been spent without checking first.

GPSports would like to hire a Java nerd for a few months to help us out with an impressive looking deadline. If you’re looking for a fun job in a neat company in Canberra for the next few months then drop me a line.

Sometimes being around computers too much can send a nerd “binary”. They begin see things in extremes - all or nothing, something is done or ignored. For example, suppose that documentation of a proposed feature is needed for a team that has never produced documentation before. I’d probably start small and work up to a reasonable level by over a number of iterations. Those nerds that have gone binary would immediately jump to the rolls-royce solution and create (or propose) a fifty page monolith complete with sign-off forms and paragraph level revision numbers.

This problem manifests itself in other ways. Need to write to a log file during installation? Instead of using Jakarta Commons Logging or writing a simple class to do it, they feel the need to design and implement something that approaches the functionality in Commons Logging but obviously takes much longer.

What can be done about it? Not much apart from constantly being on the look out for signs it is about to emerge, and learning which of your nerds have gone binary so you can keep a really close eye on them. Those who have gone binary seem to be generally unaware of it and are often unable to catch themselves unless they are about to overdo the same thing again (ie writing documentation).

Sometimes people are ready to go and solve big nasty problems or lead a team for the first time or design a custom memory manager for that C++ server application. Sometimes not. The trick for managers is to be reasonably sure that your chosen one will succeed. If you aren’t sure then put in a safety net or someone is likely to get hurt. Consider providing a mentor/coach for the task. Another idea is to meet regularly to track progress and to arrest the slide into failure or to mitigate the consequences.

Managers have a duty to ensure that their staff are not placed in a position where they are likely to fail or where failure will cause them to suffer. To do so unfairly risks reputations, happiness and health. I’ve seen too many decent, hard-working people damaged by careless and selfish task assignments. This is not to say that people should be mollycoddled. There is a middle ground.

Do you send people out to fight dragons before they are ready?

I recently became an employee after a few years of being a hired gun/nerdherder/developer.

For the last year or so I’ve been working to develop a web application for a small, local company. Eventually, the thought of leaving them once they didn’t have a pressing (and somewhat expensive) need for me grew so painful that I “offered” myself to them a few months ago. Thankfully they also wanted to keep me around (maybe as a mascot??).

So now I’m the CTO of a small high-tech company that produces hardware and software to help people improve their athletic performance. They are called GPSports and they/we are going to release a bunch of new and exciting products this year. It should be as much fun as I’ve ever had in my professional career.

Its nice to have a home again, especially in a small and exciting company, and to be committed to more than just the project I’m working on. There is nothing like being able to quickly feel the effect your work has on a company. (It is better when the effect is positive rather than negative but either way you know your alive.)

Brian Kennemer linked to my bent triangle post and noted that despite some bending of the triangle there is still a relationship between resources, scope and duration in a project. In this he is right - they are linked and it always pays to consider all three project aspects when considering a change to a project.

The main subject of this post is his comment:

“…higher quality code takes longer to write”

I think Brian is wrong. (As you read on, also note that my original post covered both code and process quality.)

The first, and most compelling refutation (at least for me), comes from personal experience. Once upon a time I was a senior nerd in a rapidly growing services organisation. We made moderately advanced business-rule processing applications for government. Since we were growing we often put people in positions of authority before we were comfortable with their experience or skills. We also had a culture that blindly ignored process. This unhappy combination meant that we regularly had situations where a project team was making lots of noise and working like maniacs but the project wasn’t getting closer to being completed. Invariably, a little bit of attention to process and a ruthless focus upon code quality resulted in an amazing acceleration towards the finish line. For me this was a clear hint that increased quality resulted in shorter project durations.

A second experience I had was in product development. I was responsible for re-writing/porting an expert system shell from Prolog to C++ and moving it to a client/server model. A colleague and I decided that we’d approach the job with an “alternative” philosophy of pragmatic perfection. We attempted to ensure that the system was perfect at all times for doing what it did. On reflection, we used a crude form of XP or agile development. Our experiment with this philosophy was kept largely secret since our managers would have been scared by such crazy talk of perfection. The result was the most satisfying and speedy development of a high quality system I’ve ever experienced. It was blissful. The development was done in less than six months and the code base is still going strong ten years later. Once again I’d seen quality and project duration positively correlated.

It goes without saying that an appropriate process will speed project completion. At extremes, I’ve seen projects delayed needlessly because nobody knew what was the highest priority task. I’ve even seen projects, after a couple of months of “emergency” work on key customer problems, realise that they can’t find the list of key problems they were working on. These are dramatic examples of process failure slowing down a project. Less obviously, using a process that is understood and sympathetic to the experience of everyone involved will improve speed since everyone will be reading from the same hymn sheet.

I almost can’t comprehend how code quality can slow down development. In fact, I almost define code quality in terms of development speed. Almost. I actually think of code quality as consisting primarily of correctness, consistency, maintainability, understandability, and approachability. These things have a direct bearing of how quickly something can be developed. Code that is arcane or simply incorrect slows down successful delivery of a project. Likewise, code that is inconsistent or random in its structure slows down projects. Of course, if you disagree with my definition of quality then it doesn’t help to show that quality increases project speed.

I can imagine some forms of “false quality” slowing down a project. In a previous post I discussed the danger to projects of unbalanced perfection. Some people focus upon a single aspect of the quality spectrum and maximise this aspect at the expense of other aspects of the project. This results in overall quality being lower or project delays. I think that it is this type of over-maximised quality (or false quality) that Brian is referring to when he says that “quality takes longer”. I honestly can’t conceive of true, needed, balanced quality actually slowing down a project.

Am I wrong?

The iron triangle of project management is a little bent. I just don’t think it works reliably for software. And remember, there’s nothing worse than a bent triangle when trying to manage a project.

What is the iron triangle? Its the rule of thumb that says that the resources, scope and duration of a project are linked and any change to one of these three aspects necessitates a compensatory change to at least one of the others. In short it says that you can’t ask for more stuff without adding more resources or accepting that it will take longer.

So, why doesn’t this always apply to software? Well the problem has to do with quality (which is generally treated as part of the project’s scope). There are three relevant types of quality:

1. Code quality - how well structured is the code/architecture, etc;
2. Process quality - how well suited to the relevant people and domain is the development process used on the project; and
3. Business implementation quality - how well does the project meet the business need(s).

Given this, if you want something to be high quality then it will take longer or will require more resources than something of lesser quality. WRONG!!!

Consider a project with a high degree of code quality. This project will proceed more smoothly since fewer difficult to identify or isolate problems will occur. What about a project with high process quality? Again the project will be smoother since the process will be well suited to the task (and people) at hand.

The difficult quality type to demonstrate an inverse relationship with is “business implementation quality”. However, there is a neat out for me (phewww). Business implementation quality is derived from the other two types of quality - good code leads to good business outcomes and good processes lead to accurate modelling and requirements elicitation.

This means that we can place our hands on our hearts and say that an increase in scope (via quality) will reduce time and cost of software projects. Hence the bent triangle - it simply doesn’t work all the time for software.

P.S. Please note that I am explicitly not including quality in the ISO 9001, CMM, etc sense here. In my experience this stuff increases time and cost and adds little to scope.

Sometimes people are so used to artificial constraints that they come to see them as part of the natural order of things. Hang on while I try to illustrate this with a cat story/parable…

I once lived in a group house with a couple of other people (including my brother) and a cat called Camus (my brother had a Cure obsession at the time he named the cat). Unfortunately Camus was a needy cat in a household of people who weren’t home very much. So each day when I got home from work I made sure to give him some “quality time”.

One day I arrived home early. Camus was delighted - he didn’t have to wait as long as normal for some attention. I heard him coming before he got into the loungroom - patter…patter…flop…patter…patter…flop…patter…patter…flop… . This noise was accompanied by the normal extravagant purring he made when someone was around. Once he rounded the corner it was clear that he was moving a little strangely. As he got closer I worked out that one of his front paws was stuck in his collar. This made walking quite difficult for him and he compensated by taking a few quick steps before flopping onto his belly and then starting again. Despite his temporary handicap he was perfectly happy.

I’ve seem similar things happen in the workplace. Dodgey processes, too many bosses, not enough leaders, dictatorial attitudes, etc. Some of the time people are aware of the problems and can tell you. The rest of the time people know something is wrong but can’t quite put their fingers on it…until the constraint is lifted.

Have you guys seen this effect before? What’s your favourite war story? Are you suffering under an invisible constraint you haven’t been able to identify?

Stop reading here if you are easily disgusted.
———————————————————

Consider a useful process. Why is the process useful? Probably because it helps to avoid some sort of cost or (better) to provide some benefit. In some cases a process, like making sure your parachute is properly strapped on, will help to avoid a disaster. To illustrate how a disaster can be avoided using process I experimented on myself.

Here’s how I did it:

1. Yesterday I flagrantly ignored the kitchen paper replacement process that has been working at my house for years - “when the last sheet of paper is finished on the roll get a new roll out of the cupboard and put it in a convenient place in the kitchen”.
2. This morning I paced around the house, in bare feet, talking to my friend Chris VL on the phone discussing the need for a coffee at the God’s Cafe this morning.
3. I didn’t look where I was walking (due to animated conversation about the benefits of coffee) and I trod in cat vomit in the middle of the floor! Gross!
4. After the initial revulsive concussions racking my body subsided I thought that it would be okay, I can just hop to the kitchen (a metre away) and wipe my foot with kitchen paper. No worries.
5. I hopped to the kitchen, opened the draw where the paper is kept and, as you have already guessed, it wasn’t there. At this point I recalled my flagrant process violation and panicked.
6. Military Grade Disaster!!!!!!

As you can see process can avoid disaster. Believe me.