Leon Brooks picks up on my previous post about motivating via competition, suggesting, if I understand correctly, making cooperation a key to winning the competition. It seems to me that coming up with a system of rules to encourage team work is doing things the hard way. If you want people to work as a team, make them a team. Put them on the same side, all striving for the same goal to get shared rewards.

Competition is a strange beast – it can bring out the very best in people and it can cause teams to gel better than they ever have. Something about having a challenge thrown out with the potential to feel superior really gets people motivated. Sadly, there is a trend to try and use this motivation in the workplace by having awards and competitions between work mates. Instead of bringing the team together though, these competitions tear it apart because now the aim is to be superior to your work mates instead of working with your work mates to be superior over someone else.

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.

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.

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.

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.

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.

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.

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.