Host your own Windows7 launch party?

At a loose end? Why not host your own Windows7 launch party? Here's how.

Thanks to Neil Hume of FT Alphaville for this.

What shall we do with Gordon Brown?

Moonwalker Buzz Aldrin says a global leader should commit to sending a man to Mars.

Go for it, President Obama. And may I suggest Gordon Brown as the lucky spacefarer?

IBM says world will drown in data next year

According to IBM, "Experts predict that by 2010, the amount of digital information will double every 11 hours."

That's really, really scary. If the amount of data were to double every 11 hours, it would quadruple every day. Over a month the quantity of data would increase by a factor of 36,893,488,147,419,103,232 (roughly speaking). Over a year it would increase by a factor of ...

No, I'm not going to work it out. But if anyone from IBM reads this please can you buy a calculator for the marketing department.

Element 112 needs a name

A German team is looking for a name for an element that's just about to join the periodic table.

Element 112 is super-heavy and very unstable. It falls apart in milliSeconds.

Gordonium?

Oh, the Coder and the Tester can be Friends, can be Friends...

(with apologies to Oklahoma!)

Elisabeth Hendrickson just tweeted about a thought-provoking analysis by Michael Bolton of the much-vaunted Continuous Deployment at IMVU.

I'm a big fan of TDD, Automated Tests and Continuous Integration, but I'd hate to develop without help from good Testers. A couple of years ago I worked on a dream project; a very small, highly skilled team which included a couple of developers, a tester and a business analyst. We were pair-programming, and my pairs came from a pool that included some of the best agile developers in the UK. The Tester and Business Analyst were also outstanding.

Our defect rate was very low: five defects in UAT, none in production over a twelve-month period. There's no doubt that this was a team effort; the Tester and the BA both caught many defects that were caused by problems we developers hadn't though of, and therefore never tested for. Equally, the developers tested so thoroughly that the Tester and BA could focus on the hard stuff, where their skills contributed maximum value.

For reasons that need not concern us, the application initially went into production on a machine that was controlled by the developers. We could have done continuous deployment, but we didn't. We always asked our Tester to do a final check-through on our staging box; mostly he found nothing, but once or twice he found defects that would have been real embarrasments in production. Of course, that wasn't his only contribution; our acceptance tests were the product of very close collaboration by the whole team.

So it was no surprise to read to read about Michael Bolton's experience when he did some manual testing of the IMVU site. IMVU practise Continuous Deployment, and claim to rely entirely on Automated Tests. Read Bolton's 50 Deployments A Day and The Perpetual Beta and see the consequences.

EtherPad - real-time collaborative text editing

A tweet from Eric Mack just pointed me at EtherPad.

It's a free tool for real-time collaborative text editing. As Eric says, it's simple, and it just works.

If two or more of you need to collaborate over the web in real-time on a text document, this is all you need.

Refactoring is much easier...

Refactoring is much easier when you have clearly expressed intent.

This came up a few days ago when I was talking with Steve and Nat.

We were holding a lunchtime retrospective about the latest delivery of our TDD course.

We talked about what had worked well, what we could do differently, and how we could customise the course for audiences with differing requirements.

Nat and Steve were keen to develop an exercise that would focus on refactoring. I liked the idea but I also wanted to keep an existing exercise which brings to life the value of intentional programming.

I felt that the ability to express intent was even more fundamental than the skill of refactoring.

It's risky to refactor unless you can check whether the code still does what is wanted. I don't think you can do that easily unless the tests and code express intention.

Nat reminded me that what you express, and how you express it, is different in code and tests. Good tests remind you of intent when they fail. This makes it easier to diagnose the cause of failure.

Refactoring is easiest with clean code, and clean code expresses clear intent. (Of course, as Steve pointed out, everything is easier if you have clean code).

You might refactor because the intent is not clear, but there are other reasons to do so. For example, you might refactor in order to make the code easier to change.

"The ability to pay back debt...depends on you writing code that is clean enough to be able to refactor as you come to understand your problem"

Ward Cunningham - Debt

Conclusion: we will develop a module on refactoring, but we'll keep our emphasis on writing clean code and tests that clearly express intent.

GetInLine version 2

I'm currently working on GetInLine 2 - a complete rewrite of GetInLine, a record-processing DSL I wrote a couple of years ago.

The DSL is not yet as fluent as I would like, but I'm much happier with the underlying design. I'll also be switching to an Apache license; James Strachan encouraged me to do this for version 1, but I never got round to it.

I'm following the development approach that Steve Freeman and Nat Pryce advocate in their book (and which the three of us expound in our TDD course).

I started with a failing end-to-end test. Then I used mocks and unit tests to help me to pull the required interfaces into existence, filling out the application until the first end-to-end test passed.

The resulting code is much simpler to test and write than v1 was, and I've ended up with a highly pluggable set of components.

I'll post a URL as soon as GIL2 is ready for beta testing; if anyone wants to tale a look before then, let me know.

Opportunism knocks

I've just angrily binned an invitation from the Professional Conractors' Guild.

I'm a PCG member, and I've been very happy with them. If you, like me, work as an IT contractor in the UK you'll find they offer an excellent and valuable range of services. I routinely recommend them to colleagues. So -what did they do to annoy me?

They invited me to their tenth birthday celebration.

For which I would have had to don a DJ and pay them £60.

Why on earth would they think I'd want to do that?

I'm glad they have been going for a while, but not glad enough to fork out £60. Even worse, I'd have to spend the evening talking to other IT contractors - and we'd all be wearing dinner jackets.

If the economy had been booming I'd just have tossed the invitation in the bin, but with things as they are the invitation was about as welcome as an invitation to play a round of golf with Fred the Shred. (I assume he plays golf, on the grounds that he must be good at something.)

So, PCG: I won't be joining in your narcissistic celebration, and please don't waste my membership fees on promoting events like this in future.

Read "Rocks into Gold" and spread the word!

I've just read Clarke Ching's Rock's into Gold on SlideShare. It's a delightful short story which explains how incremental delivery can improve cash flow, saving jobs in the process.

I first met Clarke at XP Day a couple of years ago. Several friends told me how much they liked his Introduction to Agile Development, so I went along. I'm glad I did.

Clarke's presentation was excellent - clear, simple, business focussed, and very compelling. So's Rocks Into Gold. I've started to use it as a resource for prospective agile adopters; I may even save a few jobs!

Read it and spread the word.