Andy Pols CTO, Entrepreneur

Some random thoughts...

Playing to win

Chris Matts and I are working on an article that looks at why IT management have a tendency to play to lose and not play to win. They tend to measure the wrong things and see IT as a cost and not a revenue generating opportunity.

The more I think about this, the more examples I see.

A friend just told me about a Bank who has told its IT contractors they must take 3 weeks (unpaid) holiday over Christmas. Apparently, this will save them £3 million pounds! This is staggering. Surely the revenue generated by these Contractors exceeds their cost?

Project waterfalls

I have just noticed an(other) article arguing that you must must be mad not to do waterfall development in the appropriately named website (

Steven Little claims IT projects must have the following process:

Step One: What do I have to do? (write the business specifications)

Step Two: How am I going to do it? (write the technical specifications)

Step Three: Do it (actually start implementation)

The print version has a wonderfully ironic photo showing the tools of the trade as hammers chisels.

I wonder why people still feel that waterfall is such a great idea for managing project risks?

Waterfall was first described by Winston Royce in the famous paper “Managing the Development of Large Software Systems”. Many people, incorrectly view this paper as the paragon of single-pass waterfall. In reality, he recommended an approach somewhat different than what has evolved into today’s waterfall concept, with its strict sequence of requirements analysis (Step one), design (Step two), and development phases (Step three).

In a personal communication with his Son (Walker Royce), Craig Larman ( discovered:

He [Winston Royce] was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes [iterative practices] within the context of the 60s/70s government-contracting models (a serious set of constraints).

Martin Fowler has blogged about my Paper

Martin Fowler has blogged the idea of a Strangler Application based the work Chris Stevenson and I presented in our An Agile Approach to A Lagacy System paper.

Here are some interesting comments about our approach:

Much of my career has involved rewrites of critical systems. You would think such a thing as easy - just make the new one do what the old one did. Yet they are always much more complex than they seem, and overflowing with risk. The big cut-over date looms, the pressure is on. While new features (there are always new features) are liked, old stuff has to remain. Even old bugs often need to be added to the rewritten system.

An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.

The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully.

ADC2004 - Party Photo

Kenji Hiranabe sent me the following embarrassing photo from the ADC closing party with my fellow partners in crime! It was a great night! Thanks Kenji!!

<img src=”/public/img/ADC_2004.jpg” border=0>

ADC2004 - Amazing Experience Reports

This morning at ADC2004 had some amazing papers (with links to the papers):

XP “Anti-Practices” : anti-patterns for XP practices

Yoshihito Kuranuki and Kenji Hiranabe presented a superb paper on the problems (anti-patterns) they had using XP. They used cartoons, play acting to totally captivate the audience. I felt sorry for the poor guys who had to follow them!

These include:

  • Brownie’s Works : “The boss refactored our code!”
  • This Anybody Syndrome : “I’m not necessary here”
  • Pairing Prison : “I’m always under observation!”

Available here

Refactoring the Development Process: Experiences with the Incremental Adoption of Agile Practices

Paul Hodgetts talked about his experience with big bang adoption of XP practices vs doing it more incrementally - one practice at a time.

This matches my experience working with teams transitioning to agile.

Available here

Subclassing XP: Breaking its rules the right way

Greg Luck talked about his experience on a project. I really didn’t like this paper when I first read it! They did not subclass XP, and he talked about only allowing refactoring at the end of the iterations! Really don’t like that!

Anyway, it turns out that he ment defer large design changes until the end of the iteration. Phew. Now I can see where he is coming from. He also talked about a pair being too small a unit to make large design decisions. I agree with that. I always use team white board sessions to discuss designs with the team. Shame the paper does not explain the story properly.

Available here