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.

I think this is the final episode in my series of responses1 to Alastair’s Responding to Adrian. What’s the aim of diffing HTML, how hard is it and how do you go about it?

The aim is really important to identify. The most common and most useful aim that I see for diffing HTML is to be able to show users what changed between two versions of a document. Since the management of most content is centralized2, this equates to showing the combined changes in each version between the original version to compare and the final version to compare. If you’ve ever wanted to see what’s changed on a wiki page, you’ve wanted this type of diff. If you’re sending Word documents back and forth between people you probably want this type of diff too.

Continuing with my response to Alastair’s Responding to Adrian, let’s take a look into the problem with invisible formatting tags in WYSIWYG editors.

The example I gave was to delete the final character of some hyperlinked text. The delete operation removes the internal formatting tag, and hence removes the hyperlink entirely, as well as the final character.

In this behaviour Outlook is no different to many other HTML editors, and is a completely appropriate example. The problem of the invisible formatting goes directly to the heart of the limitations of WYSIWYG editors. There is no visual representation of the tag, so there are bound to be some surprises when the user starts editing in the vicinity of the tag.

A while back I promised I would get around to fully responding to Alastair’s Responding to Adrian, sadly I’m finding lots of little bits of time to blog but not enough time to reply to the whole post at once. Hence, I’ll have to respond in parts when I get time.

First up, the problem that HTML doesn’t render the same on different systems. My assertion is that generally the differences aren’t significant enough to worry about.

Every fortnight or so the Ephox engineering team lets off steam by taking a couple of hours on a Friday afternoon to do cool stuff with our products using just the publically available APIs. Theres been some cool prototypes come out of it that may be turned into features later on but mostly it allows us to get a sense of what our customers go through when they try to extend or customize our products. You should see a number of improvements to our API appearing in future versions because of this experience1.

Rick Jelliffe holds the poor HTML support in swing up as an example of why Swing should be opensourced. There’s a very major flaw in this argument though: you’ve been able to fix the HTML support in Swing since at least Java 1.3 and probably well before. It was actually designed to be replacable. Just implement your own HTMLDocument and HTMLEditorKit and you can plug it into a JTextPane all you like and render HTML to your heart’s content.

Jensen Harris has a post about how they tested out removing the ability to double click in the left corner of a window to close it, but that people couldn’t get used to it so they’re putting it back. Might I suggest that people didn’t get used to it mostly because Office was the only application that didn’t allow it?

If you want to really test out whether or not people could retrain themselves (and they can, even if they complain about having to) you’d need to remove the functionality from all the windows, not just a few of them. Otherwise, the other windows preserve the user’s habits and it just becomes really frustrating that the interface is inconsistent.