One of the really core principles of XP is the idea of small, frequent releases. The most obvious benefit of this is that it allows users to see the product and provide feedback about what could be done to improve it. What’s not so obvious, but is part of the reasoning behind a number of XP principles, is that the developers benefit from this just as much, if not more than the users. Being couped up in an office somewhere slaving away creating software that no one’s using just isn’t fun. Getting your software out to users and having the feeling that you’ve achieved something is a big feel-good moment and it energizes the development team, allowing them to keep going full pace instead of getting tired and stressed.

In a comment on Software Teams Must Gel, James C. McPherson asks:

Given your brief description of the Ephox interview process, it would appear that you’re not in favour of people who work from home or are even more remote from your office. I’ve spent a long time working with remote management and geographically distributed teams.

There is, of course, no solitary correct solution, attitude or approach to building and gelling a successful software engineering or development team. I would be interested to find out what the Ephox perspective in on remoteness.

One of my keyword watch-lists pointed me to Matthias Ernst’s entry, A long term suspicion:

An observation: almost all WYSIWIG text editors suck at some point. We’ve been beaten up repeatedly for our CMS’s text editor but in comparison we’re actually doing pretty well.

Writing a good WYSIWYG editor is hard. Most people think it’s a trivial task until they actually try it and start getting user feedback about a million different things that they never thought about. That’s also why there are so many bad WYSIWYG editors out there – people start them thinking it will be easy and then find themselves in over their head, unable to keep up with the flow of bug reports, or simply sticking their head in the sand and complaining that the users just don’t get how to use the product.

We’ve been tracking a handful of metrics that we wanted to track about our code base for a while and it’s built up some pretty graphs that tend to indicate that our adoption of XP has improved the quality of our code. Obviously they’re just a guide, the real test of quality will happen when we ship the next release out to clients, but they’re useful none the less. The general trend shows a gradual improvement over time – fewer known bugs, lower complexity, more tests etc.

There is an interesting tendency in software development to try to keep the internal model as closely in sync with the output format as possible. When you control both, that’s probably not a bad idea – it simplifies serialization. What is important is that the user interface matches up precisely with the user’s mental model of how to use your software. Attempting to keep your model simultaneously close to the user’s model and the output format often forms contradictory goals.

A while back I saw a comment go by that raised my interest, it was something along the lines of: we know all our users want a better editor, but it’s just not something we can charge more for. My recent experience with Yojimbo and what I’ve seen of a number of people evaluating blogging systems, content management systems and anything else content-centric, tends to indicate that even if you can’t charge more, you’ll definitely sell more.

I’ve been playing with Yojimbo for the past week or so and it shows a lot of promise but just doesn’t quite make it across the line to something that would be useful. Essentially Yojimbo allows you to store stuff in a central location. You can add text files, web archives, PDF files, bookmarks, serial numbers and passwords. You can categorize them, label them and most importantly search them. It sounds promising and I’m sure that at some point it will be pretty awesome, but overall I found it disappointing. There were a few limitations that make it far less useful for me than it should be.

Slashdot linked off to an old interview with Kent Beck and Cynthia Andres, but it was interesting to see the number of people complaining about the pair programming aspect of XP. Comments like:

Programmers are solo beasts – putting two of these dragons behind one keyboard is asking for trouble.

and:

In the OO Programming course I had this year, they encouraged us to practice extreme programming. Well, it sucked… Everytime my partner and I encountered a little problem and one of us had an idea, he had to explain it to the other, which took at least 3 times as long as just typing it out, which in almost every case made the idea perfectly clear. Suffice to say, after about 4 hours we gave up and just sent each other any files we had edited (of course making sure we didn’t work on the same file at the same time).

If you happen to run a lot of JUnit tests in one go with Eclipse, you may find that towards the end they start to slow down or throw OutOfMemoryExceptions. They do that because the Eclipse JUnit plugin creates a new instance of the TestCase for each test method, calls setup, test method, tearDown and then for some reason keeps the object around. This means that if your tearDown doesn’t null out all the fields in the test class you can wind up with a whole lot of wasted memory.

In most software projects, there are a few areas that are just really complex to get your head around. It’s not something that refactoring can solve, the underlying concepts are just difficult to work out. Fortunately as software developers, we can learn that information once and encapsulate it in code that will understand it for us and even apply it in new situations that we didn’t originally consider.

Recently, we’ve developed a really neat, simple example of this – the PushAndPopCalulator. A surprisingly simple class that determines the appropriate values for popDepth and pushDepth when inserting in Swing text components. The push and pop depth is a way to manipulate the element hierarchy of styled documents to precisely determine where the inserted content works out. Once you understand the details, it’s a reasonably simple concept but working out exactly what values you need for a particular insert requires a break in focus on the actual problem to divert into working out details of using the underlying APIs. It takes a little more time to generalize that to cover all the possible situations you might need.

While I’m waiting for Eclipse to do an update: What’s the one value you can pass to Math.abs(int) and get a negative value from?
Just ran into a bug caused because of it – fortunately it was picked up by the tests even before I checked in.

This seems to be the simplest description of setting up a fallback font I’ve found: http://weblogs.java.net/blog/joconner/archive/2006/09/internationaliz.html

We occasionally come across clients with the problem of fonts not rendering correctly in the JRE so in future I’ll be able to point them to this article. Fortunately, with Java 1.5 a pretty good fallback font is already provided so it’s pretty rare that you need to do this these days.