Quite some time ago I talked about redefining and rewriting handler functions in JavaScript, but what if you want to add or redefine methods in an existing class? JavaScript classes1 are based on prototyping so the model is somewhat different to actual object oriented languages. Here’s one way to define a class, MyThing:

function MyThing {
  this.doStuff = doStuff;
}
function doStuff() { }

Note the use of function assignment in there, just like for handler functions. This is one way to do classes in JavaScript, and it’s not really the best – once you get your head around prototypes you’ll probably find that using them directly is much clearer. There’s plenty of tutorials around the web on JavaScript prototyping so I’ll leave explaining it to the experts.

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. 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.