Managers and HR type people are big on setting objectives and identifying a key metric to absolutely, without doubt determine whether or not that objective was met – usually tying bonuses to that metric. The problem with this is that people then game the system. If the key metric is lines of code per day, then people write excessively long, complex ways of doing things because that’s what will get them rewarded. If the metric is defects per thousand lines of code, people stop reporting bugs. For any given metric, there’s a simple way to game it and whether or not people realize they’re doing it, they will trend towards gaming the system. Overall, this leads to a net loss for the company because people are concerned about their bonuses, instead of focussing on working well as a team and doing what’s best for the company.

So Google, the company that does no evil, seems to be learning a few tricks from the evil empire of Microsoft. With the release of Google Checkout, Google have effectively implemented Microsoft’s failed passport initiative but with a purchasing spin. Most of the similarities I’ve seen compare it to PayPal1, but my first impression was that this is single sign-on for web stores and that’s more along the lines of passport than PayPal.

There seems to be a trend these days that whenever you link to some external site, you do so via a redirect script on your own site so that you can track who’s following the link and steal some google-juice in case anyone happens to blog about something you pointed them to. I’m not quite sure why, but I just find this obnoxious – maybe it’s because I’ve been frustrated a couple of times when the referrer script was down, thus breaking the link – even though the actual site was up. Maybe it’s because I resent the couple of extra seconds it takes to follow the link due to having to make two separate HTTP requests. Either way, is it really gaining you anything to put your users through this?

Jensen Harris has an in-depth look at the customization choices made for Office 2007 and why they made them. I’ve always been a proponent of getting the UI right in the first place and only providing limited or no customization abilities. Mostly this stems from Raskin’s The Humane Interface:

The central point of this issue is that if we are competent user interface designers and can make our interfaces nearly optimal, personalizations can only make the interface worse. Therefore, we must be sparing and deliberate in offering user customizations. If a user can, by a few judicious choices, really improve the interface, we probably have done a poor job.

One of the most common things touted about XP is that it allows for rapid change. The client can change the requirements on the fly for a very low cost – they can add features, changes features and drop features regularly as the product is developed without incurring a massive cost of change. When you work on in-house applications or custom built software, that provides a really big benefit, but when you develop off the shelf software that means that the final release may contain a mish-mash of new features and be generally unmarketable.

Jeremiah Foster writes about Apple closing the source to the OS X kernel on Intel. I the statement:

Without the ability to modify kernel source serious developers will not touch the Apple platform, maybe that is why the OS X server is not making significant inroads into the server community.

Firstly, serious developers don’t really care about kernel source unless they happen to develop kernels or kernel modules. Most developers, both fun loving and serious, develop well above the kernel level and don’t need access to its source code. Even the link between serious developers and those that are so passionate about open source kernels, that they refuse to use an OS whose kernel isn’t open source is tenuous at best. The kernel is one very small, albeit central, part of OS X and the vast majority of the OS is and has always been closed source.

Someone, I forget who, pointed to an old article on Ask Tog, Keyboard vs. The Mouse, pt 1. I found it particularly interesting to read that:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

I’ve always been of the mind that GUIs are faster than command lines for any task which you don’t do often enough to know off by heart. I imagine the same applies in this case – any task you perform often enough to learn the keyboard shortcut off by heart is faster by keyboard shortcut, otherwise using the mouse is faster. Unfortunately, this means that when you begin using a new command frequently, you have to go through a period of slower use in order to learn the keyboard shortcut, after which you should be faster.

In my previous post on tracking estimate accuracy, Stephen Thorne commented:

I thought the entire idea about estimates is that they should be self correcting? Estimates made in some arbitary numbering system, you sum up the estimates, divide by the time actually taken, then you have an accurate picture of how one developers estimates map to reality…

The ability to map arbitrary estimates to actual time that Stephen refers to is velocity. Essentially, how many points per time period can the team complete? This is a really effective technique if your estimates are consistent. That is, you may find that 3 points takes on average, a day to complete. So your velocity is 3 points per day1. However, if your estimates aren’t accurate, you may have some 3 point stories take 15 minutes, and some take a week.

In general, Java classes are lazily loaded into the system, so if you have something like1:

if (System.getProperty("java.version").equals("1.4")) {
    Java14OnlyClass.doStuff();
} else {
    AlwaysAvailableAlternative.doStuff();
}

The code will have to be compiled on Java 1.4, but will actually run on Java 1.3 without throwing a ClassNotFoundException. This trick however can be dangerous, there isn’t any guarantee that class loaders will always use lazy loading and even with current class loaders, there are occasionally some surprises.

Over the past few weeks we’ve been working on tracking our velocity and trying to get a grip on how many points a week we can do. We haven’t really rolled out proper iterations yet, but we pick a set of stories to work on for the week and then set about doing them. At the end of the week we add up how many points we completed. This has been working quite well except that we are regularly doing more points than we expected but not nessecarily completing any extra stories.

We’re looking for some new hires and I just can’t believe how many people don’t know how to write even a half decent job application. How difficult is it to realize that you have to:

1. Include a cover letter.
2. Customize the cover letter so it is specific to the job you're applying for.
3. Explain how you meet some of the key requirements in your cover letter and
4. Customize your resume at least a little to highlight the most relevant things for the job you're applying to.

Applying to a million different jobs with a crappy application is far less likely to get you a job than applying to two or three with a really good application. Take the time to get it right and you’ll find a job so much quicker and easier.

Feedback is a key concept in XP and it’s common for engineers to focus on feedback from the business in terms of what features are required, how to make things better etc. It is important however not to forget that feedback to the business is just as important

The business needs to know how things are going – to see that progress is being made and what the team is working on. To that end, we’ve started providing a whole series of pretty graphs showing our velocity on each project, the number of open bugs and a few graphs showing basic code quality metrics. It remains to be see how successful this will be but hopefully it will help provide some vital communication from engineering back to the rest of the business without needing an all-hands meeting every week.