Gavin Terrill's Blog

Using a Control in Unit Testing

Good entry on unit testing tips over at /dev/null.  Definitely agree with the last point: "Remember that unit tests are but a small piece of the quality puzzle". One of the common mistakes junior developers make is dismissing the idea of unit testing because "it doesn't handle system integration issues" (for example).

I find the first point about having a control case interesting. I've never used this idea in my unit testing experience, but it sounds similar to the idea used in aircraft fly-by-wire control systems. They typically have several systems running in parrellel that have been written by different developers  (Airbus calls this "multiversion programming") - for fault tolerance at a hardware level, and to validate that the outputs are in agreement across all systems.  These types of systems are architected for "Byzantime fault tolerance", protecting against the possibility of misleading signals (or output values in the case of unit tests) from components confusing the system. The point is, once you introduce the idea of a control and you find anomalies, you take on the additional burden of having to decide if it is the control or the component under test that is actually broken. I am not sure our non-mission critical application warrants this level of investment, but for the right applications I can see this being a useful technique.

Roadmaps Considered Harmful

Interesting post over at 37 signals about the pitfalls of putting forth a product roadmap - "Product roadmaps are dangerous".  The comments are interesting. Here is my favorite so far:

Unless satisfying your clients involves doing nothing for a long time, in which case I say: get new clients. Or if satisfying yourself involves doing nothing for a long time, in which case you’re a procrastinator/sadomasochist and should probably get a different job.

I hate to take things out of context, so in fairness I have to say that the previous paragraph in the comment was about the virtues of doing something real every day (an agile-esque philosophy indeed I may add).

As a software vendor, I am selling the value of my product to help you with your business. As part of that, I can't remember a pitch where the prospect hasn't asked to see a roadmap. The client needs to know that you have ideas that will be useful to them after they have bought your product. I think they also want to know the product has a coherent direction. So to us, the roadmap is a useful selling tool in helping articulate the "grand vision".

Another less ingenuous use of the roadmap is to help overcome perceived shortcomings in the product - kind of like saying "We don't have that feature right now, but it's on the roadmap". Some vendors will use this tactic to wait until enough customer momentum drives the requirement over the line. Similarly, Joel's "Fire & Motion" idea uses the roadmap to drive competitors nuts as they try to keep up with your feature announcements.

Nowadays, I spend a lot of time dealing with the vagaries of implementing our software in very large organizations where the difficultly is coordinating many moving parts and constituents. I've seen the "roadmap" used as a very effective tool to get buy in from the major stakeholders.

There are lots of different ways to look at roadmaps, but I think an important thing to keep in mind is that a roadmap is simply a snapshot of what you think are the most useful things the target market will need in n months time. More importantly, the roadmap is not a project plan, so it doesn't really matter if that Data Slicer & Dicer feature slips until next February if you do something that is more relevant now.

Software Developer Cost Benefit Analysis

Perhaps the most important thing I have learned since founding a software development business, is that you should strive to surround yourself with the best people you possibly can, and take the time to create environments that facilitate the flow,  tolerate the stuckness, and minimize the interruptions. This is neatly expressed in this article: Flow, Stuckness, and Interruptions.

In addition to "being in the zone", I think there is another critical related variable worthy of discussion: the abilities of the individuals doing the work. Brooks assertion in The Mythical Man Month that in general "good" programmers are 5-10x more productive than mediocre still rings true. The actual time taken to complete a task will be highly dependent on who works on the task. Brooks went on to advise structuring "Surgical" teams, where the mediocre folks primarily provide assistance to the good 'un. I don't agree with this, and instead proffer a naive  and simplistic solution: build teams where all the programmers are good.

Of course, critics of the naive approach point out that A) it is difficult to find good people and B) the economics don't work. I agree that item A is a difficult  issue, and therefore needs to continually be one of the  primary concerns of the management team. On the other hand, I think the economics do work in our favor.

Consider a conservative goodness factor of 3 (so 1 good guy equals 3 mediocre guys), and a small to medium sized software operation with 12 developers. We can see that we will now have 4 good guys. We will say a good guy costs a third more than a mediocre guy at $120K.

Here is the math:
4 * 120 = 480
12 * 80 = 960

Wow, that is 100% difference (funny how that works huh?). So, I can have my cake and eat it too.

It gets better with the fringe benefits:

• It scales. It actually gets cheaper the more work there is (for example if you doubled the developers in the above scenario it would be costing you 960 v's 1920).
• Management and communications overhead is significantly reduced. It takes far less time to get everyone up to speed on what is being built.
• Major problems are really major problems, and are worthy of your attention - you will not be bothered with minor problems that are invisibly solved quickly with no fuss. Good people just do this. This frees up my time, and makes me (as a manager) more effective.

Someone once told me that if it sounds too good to be true, then it probably is. So, help me out. What am I missing here?

The zen of branching

I'm enjoying the latest installment of Source Control HOWTO.

Favorite quote:

Best Practice: Don't create a branch unless you are willing to take care of it.

A branch is like a puppy.

We adopted subversion for new projects several months ago and are very happy with it. Now we are about to release the first version of one of those projects, so it should be fun to see how branch/merge works out. I am always nervous about this, having experienced disasters using both SourceSafe and CVS, so let's hope for a pain free experience this time.

Useability guidelines - 20 years on

Jacob Nielsen' latest alert says that 70% of useability guidelines issued by the US air force in 1986 are still correct and relevant. Couple of interesting stand-outs:

guideline 6.2.1 recommended single sign-on.

You would of thought we would of figured this by now wouldn't ya?!  He then goes on to point out that his internal usability measurements (conducted 10 years later) found that login difficulties due to multiple sign-in requirements are the second biggest problem in intranet usability (the biggest being search usability).

Guideline 4.2.6 said to provide a unique identification for each display in a consistent location at the top of the display frame.

I still think this is useful (not to mention it makes life a lot easier for AppConnector), even if Jakob doesn't necessarily agree. I'm thinking along the lines of support here.

When you think about it these finding aren't that surprising for a couple of reasons:

1. They are guidelines, which by definition tend to be fairly generic
2. Not much has changed in terms of GUI design over the last 20 years. We pretty much interact with systems the same way.
3. And as Nielsen points, people are slow to change. Trying to introduce new useability paradigms is an arduous task.

OO CMM

Aint it the truth: OO Programmer Levels - A Capability Maturity Model for Object Oriented developers.

WetWillyWiki

I would recommend anyone who is not using a Wiki to facilitate communication and documentation on an agile software project have a read of this:  Using a Wiki for Documentation and Collaborative Authoring. Good read.

[via Column Two]

Using a Wiki for Requirements Management

Large organizations tend to shy away from "loosey-goosey" agile methodology techniques (such as UserStories) as they fear losing control of the project. These types of institutions prefer a Waterfall based approach. Of course, imposing such rigidity hinders collaboration and curtails flexibility. Johanna Rothman touches on this in her blog entry "How Many Process People?", where she says Agile can work, so long as there is traceability around the requirements. Great advice.

We are currently working with a client in a regulated industry. We proposed describing the functionality of the system using "Use Cases", hosted on a secured Wiki. Now, the client has a consultant. Consultants like to "add value" so they can justify their pay, so I guess we should of seen this coming but the term "Use Case" got hijacked and in its place was something that took me back to the COBOL programming days at the Department of Finance in Oz. You know, where you sit around for six months waiting for an assignment to write a sort routine. Data input is PIC 99999. Output must fit in a 80 column wide report. Blah, blah, blah... What ended up happening is we abandoned our collaborative efforts, and the dev team started a new internal Wiki. Such a pity, as the other business users and the dev team were really starting to gel nicely.

In retrospect, the inputs from the consultant were valid, but not in the Use Case format.  What got lost is the notion that there are other artifacts that can be used to capture different aspects of the end system - for example a Data Dictionary. The key though, is to describe these facets in separate documents (pages), then create links between them where appropriate.   Wikis are great for this, especially if you have one that tracks versions of the pages.

A good software architect will create layers of concern in a system to reduce coupling - requirements management is the same. Mix it all up and you run the risk of ending up with "spaghetti requirements" - no one can read or understand them.

Mmmmm.... Me like!

How cool is this:  http://www.clarkware.com/cgi/blosxom/2004/11/17#GearOnDisplay

Automate your build, and have some fun with it.