It seems I finally pestered Doug into blogging again, so for his side of the story check out Experiments in Software Design.

Bob is our build server – just like the children’s TV character, he spends all day building stuff. Bob has to be one of the most beneficial improvement projects we’ve taken on at Ephox in quite some time. Every build of our key products that we ship both as full releases and hot fix patches are built by Bob. He even uploads them to the web server when told to make them available to clients.

One of the tenets of XP is that you work at a sustainable pace. Mostly that means that you don’t work such long hours that your brain turns to mush and you start churning out bad code, however there is more too it.

Working at a sustainable pace also means knowing when to take a break from a task. After weeks of slogging away at replacing this 3rd party library – constantly making progress and getting small wins from each acceptance test we got to pass – this afternoon both Doug and I seemed to have stopped caring as much as we should, so we took the afternoon off of that project and went and caught up on the other things we needed to do. When we return to working on it we should be refreshed and able to approach the problems with a more open, creative mind and thus write better code.

Doug and I are currently busy replacing a third party library which we’ve used in our product for quite some time. Thus, the first thing we need to do is create a new component which behaves in exactly the same manner as the original component. Once we have that we can start adjusting the code to add features and work in the way we really want.

To ensure we get an exactly compatible replacement, we started out by creating a suite of automated acceptance tests against the original implementation and they all passed.  Then we removed the third party library and they all failed. From there we could gradually begin building our new component by attempting to make each acceptance test pass – one at a time.

Claim: TDD Generates High Quality, Maintainable Code

Proponents of TDD argue that by writing the tests first, you are forced to focus on how the component will be used and thus will come up with a better design. My experience has actually been the opposite; TDD encourages you to just do whatever needs to be done to make the test pass and not think about design at all. I’ve never copied and pasted code so much in my life and the number of times I’ve written code that’s so messy I feel like I need a shower is getting scary. That’s okay though, it’s meant to be that way. TDD encourages short-sightedness, short-cuts and general sloppiness and that’s a good thing.

So we’ve got a huge chunk of legacy code (making up 3 main products and a lot of integration products around them), automated builds after every check-in and a bunch of tests that are somewhere between unit tests and integration tests and a team of developers who haven’t had any significant experience with XP (excepting our new hire, Doug South, who’s to blame for the XP idea in the first place). Did I mention tight deadlines and ferocious competition? We don’t have time for down-time, we need to get this process up and running and quickly and smoothly as possible.

The Ephox engineering team has decided to start adopting XP, mostly to help improve quality but also to help respond more rapidly with the changing priorities and requirements that commercial software tends to live with. I’m hoping that I’ll be able to keep a fairly good record of the process here so that over time I can look back at the challenges we’ve faced and see how we’re doing. I’m also hoping that by detailing my thoughts and experiences here that the lazy-web will chime in with useful comments, corrections and ideas.

Loud Thinking:

Finally, the new economics of dynamic languages like Ruby simply makes reuse a lot less attractive. Since the cost of producing new, original code is so much lower…

Hang a tick, why is new code cheaper with dynamic languages? Sure, you can write the code faster but the vast majority of cost involved in code isn’t spent up front, it’s spent in maintenance. So writing new code hurts because you don’t take advantage of all the money already spent on maintaining existing code and instead incur extra maintenance cost.  Even if the initial cost of writing new code was reduced to zero, new code would still be very expensive purely because of the maintenance element.

I’ve been mostly ignoring the uproar about how Steve Jobs “lied” about how much faster the Intel iMac is opposed to the G5 iMac. Expecting benchmarks to reflect any form of reality is just plain ignorant of the complexities of modern computing.

Despite thing, there’s a great irony which has just dawned on me. If Steve Jobs is clearly lying about how much faster the Intel iMac is over the G5 iMac, then clearly he wasn’t lying when he was pushing the G5 chip and pointing out how fast it is compared to those crappy Intel chips. You remember those old photoshop bake-offs that everyone mocked right?

Here’s a tip for you, anytime you hear someone say, “The XML specs aren’t really that complicated”, you know they haven’t tried to work with XML in any detail.  For a start, as soon as you start using the term “specs” instead of “spec”, you’ve got something that’s going to difficult to piece together.  When you get to the vast number of specs involved when working with XML, you’ve got a weeks reading just to get through them all.

I’d like to be able to play around with the photos in my iPhoto library without having to export them first. Do APIs exist for accessing this stuff or is there an opensource library available somewhere that can read the iPhoto Library data? Google searches tend to indicate there isn’t any but I thought I’d ask the lazy web.

Brain Sparks has an interesting critique of the findings from that infamous study suggesting that users make judgments about a web site in the first 50ms. Turns out there’s no evidence in the study to suggest that users will leave your site if that first 50ms doesn’t look good – they’ll just think it’s ugly.

Thankfully, we’re not as fickle as some people seem to think we are.