Which way to Zurich?

Just let Google Maps show you.  Pay close attention to leg 36 of the journey.

And if you're confused, it will also show you an itinerary that avoids lands on the way.

One thing missing is that the map doesn't tell you where to buy a swim suit.

Our own, agile ways

This article about agile development is filled with very revealing contradictions.

The people quoted in this article, both with an obviously strong vested interest in agile techniques, are trying to convey the idea that agile practices give users the utmost priority, and that work will not stop until users are 100% happy:

Then the developers can go back and refine their work, repeating the process several times until the users are satisfied.

However, the rest of the article shows that users are, in effect, given very little part in the overall process. Here are a few quotes that made me pause:

It's not important to deliver on time but to deliver something that works

This is an observation that's hard to reconcile with the idea that you are working to make your users happy. In my experience, nothing makes users happier than delivering on time. And if development reaches a point where the initial deadlines are suddenly put in question, the best way to solve this problem is to ask the users: "We can ship on time, but then we'll need to cut feature A. What would you like us to do?".

Another interesting quote is:

While Ford agreed that it's critical to deliver software that meets users' needs, he acknowledged that it's important to be able to predict when a project will be completed. But developers, business analysts and project managers need to work together on this.

Do you notice anything in the last sentence above? The users are nowhere in the picture. They are not part of the loop. This leaves us with a disturbing impression that developers, business analysts and project managers know better what needs to be done and that they will let the users know once they've made a decision. This sounds dangerously like Waterfall, which is exactly what we were trying to avoid in the first place.

The article continues with more startling claims, such as:

It's a bad idea to ask developers how long it's going to take to do something because it always varies. Every project has different characteristics

Do you know the difference between a good developer and a bad developer? A good developer can give you an estimate of the time needed to complete a task. And the better that developer is, the more accurate their estimate will be. If I ask a developer "How long is it going to take to do this?" and he answers with "It's very complicated", I want him off my team.

To determine the length of a project, the project manager gives the user stories to the developers to decide such things as the programming language that will be used, the architecture and the framework. After that, they sit with the business analyst and go over the story cards and rate their complexity on a scale of one to eight.

This part reminds me of a scene in Dead Poets Society, where Robin Williams asks his students to look at a page in their poetry book that is trying to rate poetry on X and Y axes. Williams then tells his students to rip that page because poetry is not about metrics or scales, it's about art and using one's expertise and talents to reach a goal.

And the more I think about it, the more this process with cards and business analysts assessing the load of work reminds me of Waterfall. The developer's know-how and expertise accumulated over the years is thrown out of the window and replaced with vague numbers and concepts that not even the most hardcore agilists agree on.

We don't need agile consultants and book authors to sell us vague and unproven metrics along with rigid guidelines that your team must embrace without any questions. We need to hear from people who defend agile practices and yet have no financial interest in them. We need good and experienced developers to be recognized as true experts about what constitues good software products and sound engineering practices.

The world has already moved on to something called "agile". Very few people agree on what it is exactly, but they all accept the fact that it means "not Waterfall". We don't need to be convinced of the idea that Waterfall development does not work very well, and that it's much better to engage in a continuous dialogue with your users to make sure that the right tasks are being performed in timelines that everybody agrees on.

A lot of people are snickering at the kind of agile rhetoric shown in the article I quoted, because while such logorrhea makes for an entertaining read, the last thing we need is being patronized by snake oil salesmen trying to sell us something we already know.

Until agile evangelists catch up and become truly agile, we'll just keep developing our software with our own, agile ways.

Designing for Testability

Today, Alexandru and I made our presentation at QCon. We split the talk in two parts: Alexandru covered a section we called "Three TestNG features that you will like" and I followed with a brand new presentation entitled "Designing for Testability", which I made purposely non-TestNG specific.

As you probably guessed, a lot of the ideas discussed in this presentation are covered in greater lengths in our upcoming book.

Here are some of the topics I covered:

• Designing for Testability can sometimes be at odds with well-established software engineering practices, such as certain design patterns and extreme encapsulation. You need to be ready to question your beliefs.
• You should avoid using statics, and there are some very valuable frameworks that make this very easy (Guice and Spring, to name two).
• Test-Driven Development does not necessarily lead to code that is better designed, and is best used to expose junior programmers to testing.

As for the conference, I'm enjoying it quite a bit: the location is absolutely terrific and it's nice to be able to attend non-Java tracks, for a change. Hats off to Floyd, Alexandru and the rest of the crew for a top-notch conference!

Sheep, camels and llamas... all in space

Jeff Minter recently made a presentation at Google.  If you are not a gamer, Jeff is a very prolific programmer with a perplexing obsessions for animals and an undisputable talent for writing top-rated action games.  He started his career on Vic's and C-64 and he's been repeatedly known to push the limits of whatever hardware he was programming on.  All his games feature spectacular psychedelic effects and sound tracks that are guaranteed to make you laugh even if you're just watching the game.

Jeff went through a quick history of the games he worked on and concluded on his current project, called Space Giraffes.  Here is a quick overview:

• GridRunner, on C64.  A Centipede-looking game that is going much faster than any you've seen.
• Attack of the Mutant Camels.  A Defender-like game that includes giant camels that got in trouble because it was looking too much like The Empire Strikes Back.
• Sheep in Space.  A space shooter with a sheep as a...  ship, that needs to land and graze on grass to refuel.
• Llamatron.  A supercharged Robotron, probably his most famous game.
• Tempest 2000, on the Jaguar.  When he presented this game to Atari, he was told that he wasn't programming the console correctly.  Tempest became the number one selling game on the Jaguar and he was hired at Atari shortly afterwards.

His current project is Space Giraffe, on the XBox 360, a souped up version of Tempest.  Jeff spent some time showing the game and explaining the thought process behind the logic, how the hostiles work and react and where his inspiration comes from.

If you've never played a Jeff Minter game and that you like fast-paced action games with an edge, you know what to do.