Red, Green, Kaizen

Back at the beginning of September Kevin Rutherford tweeted:

‘Anyone know the Japanese for "red, green, refactor” ?’

Now as it happens I know a Japanese speaker very well. Red was easy “akai”. Green was a little tricky because the Japanese actually have two words for Green, “aoi” and “midori.” We went with midori.

Refactor was a little bit tricky. After all, there was no such word in the English language until Martin Fowler published Refactoring. Indeed, “refactor” still haven’t made it into my English dictionary.

My translator suggested the Japanese would probably stick with the English term so we got “akai, midori, Refactor.”

At which point Kevin asked: “akai, midori, kaizen?”

Its taken me a few weeks to have an in-depth conversation about this with my translator but it seems Kevlin is right.

Kaizen is actually two Japanese words:
Kai: change
Zen: good

So the net effect is: “to change [improve] for the good”

Which seems to sum up refactoring perfectly.

Now, any other Japanese speakers out there like to refactor?

And just a gentle reminder that Changing Software Development is now available in Japanese. My personal Japanese translator didn’t do this translation, it was handled by the Japanese publisher.

An Agile Reader - buy it now!

When I deliver training courses I like to give participants something to take away to read, something that is more readable than PowerPoint slides. Sometimes participants get a copy of my book, Changing Software Development, but that is expensive to me and not always appropriate. (These days I tend to tell people CSD (as I call it in private) is an advanced Agile text, not an introductory one.)

A few months ago I decided to put together “An Agile Reader.” This is a mini-book, its a collection of articles which are interesting for someone new to Agile and decidedly shorter to read than Changing Software Development.

Anyone who’s been on a course with me in the last couple of months will probably have seen a copy of this. The feedback on the mini-book has been good and at recent conferences I’ve given away some spare copies.

So I’ve decided to make it public.


If you’d like a copy you can buy a physical copy here, or download the complete PDF. Price is £4.99 for the physical copy, currently discounted to £3.99 or £1 for the electronic.

I don’t see this as a new book, I prefer to call it a mini-book. Its a collection of essays, most of which you can get for free from my website or this blog. Its self-published using Lulu, its not been professionally copy edited and its not got an ISBN number.

Let me know what you think.

Cranfield study Supporting the alignment trap

I’ve blogged before about “The Alignment Trap” (Originally in December 2007 and after my piece in The Agile Journal in February 2009). This is the counter-intuitive evidence that sometimes doing things right is more beneficial than doing the right think. I often discuss this in my presentations and there are two standard reactions: for some this research rings true while others question it.

Those who question it often ask: is there any other evidence?

Well, there just might be.

Delivering Value from Information Systems and Technology Investments: Learning from success is a survey report from Cranfield School of Management in the UK. I only heard about this report a few months ago and its is now four years old but I see little reason to suspect things have changed since 2006.

The researchers define four levels of maturity in organisations developing systems. The first level is project delivery with the focus on the supply side. In order to reach the higher levels organisations must first be able to successfully deliver the IT projects they undertake.

In other words: doing things right is a prerequisite to success.

(I should point out that this report has nothing to do with Agile, Waterfall or any other method. Its about the ability to realise benefits from IS/IT projects whatever the approach.)

The second level of maturity concerns realising the expected benefits from projects. Here attention expands from the supply side to look more at the demand side and whether the business cases proposed are realistic. It is here that “doing the right thing” starts to be the issue.

Levels 3 and 4 concern realising benefits consistently across the whole portfolio.

The report contains some other nuggets of information which are with reporting:

• 73% of survey respondents said significant improvements were needed to get satisfactory value from IS/IT. (This 73% is curiously close to the 71% of companies in the “Maintenance zone” in the Alignment trap report.)
• 38% of businesses openly admit benefits are overstates in business cases in order to obtain project funding
• 80% report that review of work against the original objectives is inadequate

Finally, the other statement is worth analysing from this report is:

“The data also indicates that organisations have undue faith in business cases and that the deployment of formal methodologies gives managers a false sense of security, perhaps an excuse for not becoming sufficiently involved.”

If we take that statement apart it supports the Agile approach:

• “Undue faith in business cases”: Implies more tools are needed to tackle value. Agile would suggest a try, experiment, fail-fast, fail-cheap approach


• “Formal methodologies ... false sense of security”: That could be PRINCE2, Scrum or something else. The methodology doesn’t have the answers. You need to be pro-active and think for yourself.


• “Not becoming sufficiently involved”: Yet again we hear that lack of customer/user/manager involvement is a cause for failure. We have a few tools for working around these problems but nothing beats having actual involvement.

Cambridge edition of Objective Agility now online

Slides from my Agile Cambridge 2010 Objective Agility: What does it take to be an Agile company? online now.

Reuse Myth - can you afford reusable code?

In my Agile Business Conference present (“How much quality can we afford?”) I talked about the Reuse Myth, this is something always touch on when I deliver a training course but I’ve never taken time to write it down. Until now.

Lets take as our starting point Kevlin Henney’s observation that “there is no such thing as reusable code, only code that is reused.” Kevlin (given the opportunity!) goes on to examine what constitutes “reuse” over simple “use.” A good discussion itself but right now the I want to suggest that an awful lot of code which is “designed for reuse” is never actually re-used.

In effect that design effort is over engineering, waste in other words. One of the reasons developers want to “design for reuse” is not so much because the code will be reused but rather because they desire a set of properties (modularity, high cohesion, low coupling, etc.) which are desirable engineering properties but sound a bit abstract.

In other words, striving for “re-usability” is a developers way of striving for well engineered code. Unfortunately in striving for re-usability we loose focus which brings us to the second consideration.... cost of re-usability.

In Mythical Man Month (1974) Fred Brooks suggests that re-usable code costs three times as much to develop as single use code. I haven’t seen any better estimates so I tend to go with this one. (If anyone has any better estimates please send them over.)

Think about this. This means that you have to use your “reusable” code three times before you break even. And it means you only see a profit (saving) on the fourth reuse.

How much code which is built for reuse is reused four times?

I would suggest the answer to this question is: very little.

Consequently development teams which write a lot of reusable code are costing their organisations a lot of time and money. Waste.

Reusable code is not the solution to any of our IT problems. It is a supply side only solution and not a very good one at that. While it may reduce the amount of code that is written it reduces it by artificially constructing supply rather.

Thus, reuse, as a solution to software supply problems, is a myth.

This leave two questions we need to answer.

First: how are we to get those desirably engineering properties if we can’t/don’t push reuse?

The good news here is that Test Driven Development, i.e. writing code that can be automatically tested with other code we write, also has the effect of promoting modularity, high cohesion, low coupling, etc. Thus the answer to this question is: Make your code testable.

This approach will retain focus and deliver worthwhile benefits.

The second question: How should we manage reuse? After all, there are some genuine situations were reuse is the right answer.

Here there are two answers, a micro and a macro answer.

The micro answer, when your working in a development team is: look for emergent reuse.

Don’t plan for reuse but look for opportunities to reuse something that has gone before. When you see the opportunity take the previous work and enhance it just enough to reuse it in your case. This way you only pay the price for what you actually need when you need it.

If you later find the same code is useful again then repeat the process. Improve it just enough to use it a third time.

Remember: you have the tests from the earlier answer to make it safe to do this. Without the tests things get difficult.

Now you’ve reused your code three times, you’ve pay the price a bit every time, and you have the tests to show it still works. By now the code is going to be getting pretty close to generically reusable.

Still, maybe you go round this look a third or fourth time. It doesn’t matter is making one piece of code reusable costs more in the long run than it would have done if you did it the first time because... You haven’t spent money making a lot more code reusable that never needed it.

Telling the future is hard. It is difficult to know whether code will be reused or not, so default to Not and save the money. Occasionally you will be wrong and it will cost more, but overall you will be right and you will save money.

The macro answer: if this code really is widely reusable by many people then, go into business. Market this as a library, a plug in, an application what ever. Let the market decide the economics of reusability.

Agile Eastern Europe slides online

My conference overdose continues with Agile Eastern Europe in Kiev this week. This was going to be a simple repeat of my Business Analyst in Agile talk which I’ve given a few times before.

But somewhere over Germany I started playing with the slides. I pulled in a bit of “Objective Agility”, took a bit out, changed other bits. So the slides are different: The BA role in Agile Development (Kiev edition.)

If I’m being honest, I don’t feel this presentation worked as well as I’d like. Maybe because I changed it, maybe because I’ve delivered it too many times before, maybe because it was 3pm.

Time for reflection. Sorry Kiev, will try harder next time.

Quality - How much can we afford?

My presentation from the Agile Business Conference (ABC) 2010 is now online: Quality - How much can we afford?