I realized an unintentional side effect of deciding to not use the ternary if (a ? b : c) – there’s a bunch of code that we don’t duplicate that we otherwise probably would have. In particular, when working with views there’s a very common pattern to convert between a Shape and a Rectangle1:

Rectangle bounds = shape instanceof Rectange ? (Rectangle)shape : shape.getBounds();

The reason for this is that getBounds() on a Rectangle will create a new Rectangle instance so if you happen to be getting the bounds a few thousand times every time you go to paint the text pane, you generate an awful lot of useless rectangles. Since every shape passed in is in fact a Rectangle, you can eliminate all of that junk without risking a ClassCastException if at some point you do get a different type of shape.

Once you have an automated build, the next step is to automate deployment1. A lot of people take this to mean that you should be able to check out the code, compile it and deploy it all from your local work station. I think this is largely a really bad idea.

Firstly, if you have deployment system that needs to vary, or might in the future need to vary, based on the version of the product, then your deployment scripts have to be in source control with the product and be branched and versioned just like the actual source code. If your product just spits out a zip file that is uploaded to a web server for clients to download, you my want to separate the deployment of that zip file from the code base since it will change based on changes to the web server, not changes to the code. You should however still be able to build the zip file from scripts that are versioned with your source code.

Having a fast build is an important part of XP so that the continuous integration cycle doesn’t take too long. Do people usually see this as including all the acceptance tests as well or does this just include the developer’s tests?

How do people handle acceptance tests failing? Does it cause the build to fail or not? What about acceptance tests that have been added for the current iteration but haven’t been implemented yet?

There’s a lot of talk about how you convert a legacy project over to TDD, and there’s a lot of talk about how you TDD on little code examples, but how do you get started on a real project? For a swing app, how do you TDD public static void main(String[] args)?

Atomic testing wants you to be able to mock out your dependencies, which leads to things like dependency injection. Somewhere along the line though, someone has to create those objects and pass them in. How do you atomically test that?

In James Shore’s chapter on Continuous Integration for his upcoming book, he strongly recommends using synchronous integration, where each time you check in you stop and wait for two builds to complete before moving on, in favor of asynchronous integration, where you check in and move on to your next task leaving an automated build server to check everything’s still okay. The whole point of continuous integration is that your team integrates regularly, so that you avoid conflicts. I can’t see how this is encouraged by adding up to twenty minutes of work1 every time you want to check in.

Recently there was a security flaw introduced by a security patch for IE, this obviously is a really bad thing and something the IE team1 have received a lot of criticism about for some time. Obviously, the IE team took it seriously and tried to find ways to make sure it didn’t happen again. One thing that really bothered me though was a statement in the IEBlog:

In parallel with making the right fix, we have been working through how we prevent similar mistakes from happening again. For instance, we have code-reviewed the past ten months of code check-ins from the developer responsible for this issue.

I’m glad Andy side-tracked into talking about us temporarily dropping pair programming – I’ve been considering the same kind of things but want to see what the rest of the team thinks about it before I say too much.

Slightly off topic, the development speed we’re achieving now is making me wonder if the tradeoffs when developing purely under Pair Programming are actually worth it.

There’s a lot more that has changed recently that has led to our sudden improvement in velocity – not just pair programming. For a start, we’re more focussed on the task because we’re not sharing the support load around the entire team. Plus, the business has really started to understand how difficult it will be for us to get things done so they’ve gotten off our backs about everything else and really focussed on hitting this big scary deadline. We were splitting our development efforts between two or three products and the context switching was killing us.

As part of the process to open source Java, Sun have switched from using codenames for Java releases to just using the actual name. Thank goodness for that. I’m not sure I know of anything more frustrating than attempting to have a conversation with someone using code names instead of actual versions. Was Dolphin before or after Mustang? Which Tiger do you mean, Mac OS Tiger, Java Tiger or Tiger Direct? How hard is it to just pick a version number and use it? Does marketing really need to mess around with that number at all, and even if they do, do they really have to wait until the very end of development to pick a number?

Sam Ruby – Time for a new HTML Validator?:

If people feel that HTML 5 deserves a better validator, I’m willing to invest some time into coding. Are there others interesting in contributing to the coding, the writing up of test cases, or the authoring of documentation?

 Is there a reason we need a new validator instead of just improving the existing one? The source code is available in CVS and there’s some brief instructions on how to contribute. Admittedly it doesn’t look like the easiest project on earth to jump into but it looks possible to do so. Is noone around to accept and apply patches?

Okay, so I’ve converted my WordPress install to use Atom 1.0 and (I think) made using it as the default1, but I’ve got one warning left that I just don’t get:

line 8, column 86: Same-document reference: http://www.symphonious.net/2006/08/13/those-who-still-need-classic/ [help]

... /08/13/those-who-still-need-classic/" />

Now I get that the two URLs are pointing to the same place, but why exactly is this a problem and what URL am I supposed to put in there? Should I just make up a new base URL so that it’s clearly not the same document? The URL is absolute so the xml:base shouldn’t affect it.

Chris Adamson talks about the disappearance of classic support now that Apple has switched to Intel. It’s true, pretty much everyone has moved on from using classic apps, but there was one place I knew I could turn to find people still waiting for their favorite app to be updated: the HyperCard mailing list. Even there though the number of questions about intel are pretty light on as nearly everyone has moved on to HyperCard alternatives or just moved on to something else altogether.

The XP process allows so much flexibility in getting things done but this comes at the cost of focus. I’ve previously talked about how product managers have to be careful they don’t abuse the flexibility in XP, but recently Ephox has discovered the huge benefit that being focussed can be, even when you’re doing XP.

We’ve come up against a very tight, very important deadline for a really big, really difficult new feature and at the same time we lost our entire support department so all support fell into the engineer’s laps. Support is just one of those things you have to do as a software company and our first impression was that the extra support load would reduce our velocity but we’d be able to share the load around the team, get the day’s cases out of the way and get back to developing. What actually happened was the entire engineering team wound up doing support all day and development stopped. Worse still, the team felt drained and tired all the time. We should have been able to get support out of the way faster and get developing, but for some reason we couldn’t.