Mock Turtle Soup

When will we ever learn?

I've just finished an excellent little book, A Computer Called LEO by Georgina Ferry (1), about the history of the Leo, the first business computer in the world (2). Commissioned by Lyons, the UK's leading catering company at the time, it was a technical triumph but lost out commercially. A friend of mine, Alan Keen, actually worked on one in his youth and found it an excellent machine.

What patterns can we recognise?

Good

• A Few Good People Work with a small number of the right people and let them get on with it. Put the emphasis on the task, not on status — the juniors were involved in key business decisions and even the most senior programmers had to get their code checked by someone else before running it. Don't let the organisation get in the way of people from different teams, such as hardware and software, talking to each other to produce a combined solution.
• Provide real benefit What really interested the people who ran the place was organisational efficiency, the machines were just an effective tool for getting there. Some installations lasted for decades because they did the right job. At each installation, the programmers got involved in the design of the organisation and then fitted the machines into that; the one time this failed was when they talked to the customer's accountants rather than the end users in engineering. Nowadays we know this as Consultancy-led sales.

Bad

• Gross underfunding They had far too few people and resources for what they were attempting to do. At the time, the Americans were spending hundreds of millions on developing competing machines.
• Arrogance A traditional Cambridge failing, they were so good that they thought that the quality of what they were doing spoke for itself, but that only happened when the customers were sophisticated enough to understand. Many people dismissed their achievements because they came from a chain of tea shops, rather than the military. The Leo company never had the organisational depth to support growth.
• Wrong product They never managed to charge appropriately for the consulting that went with each sale, which drained the team without bringing in revenue, especially as the customers liked to hire away the staff. They thought they were selling boxes, rather than solutions.

In the end, the Leo company was sold off to English Electric who misunderstood the product and imposed a hierachical organisation. Finally, the government arranged a shotgun wedding of all the UK vendors into ICL and the rest, as they say, is history.

Although the motivations of the original sponsors were Taylorist, to come up with exactly one way of processing data, their approach to the Leo team had many Agile aspects. They certainly had courage, to commission a radical use of such a new technology; they emphasised communication to make sure that the team was effective and that they implemented the right applications; they had techniques to feed back errors that ensured the reliability and correctness of their system; and they probably valued simplicity too.

The morals of this tale?

• We've have known the right way to get things built since the earliest days of the computer, because after all it's about people not hardware, but precious few organisations seem to be able to do this.
• Customers who want cheap, effective solutions have to have internal staff who know what they're doing, otherwise they'll spend a lot of money on some Magic Solution. Something to remember in these days of oursourcing.

---

(1) Published by Fourth Estate, ISBN 1-84115-185-8
(2) It ran a Bakery Valuations program on 25th November 1951.

Are Mock-based unit tests really too brittle?

At XPDay London, Tim Mackinnon and Joe Walnes presented a tutorial on using Mock Objects to drive top-down design. With Nat Pryce and me, they make up a Gang of Four who've been reworking our thinking about Test Driven Development with Mock Objects.

Martin Fowler was there giving a keynote and came to the tutorial. We've been having an ongoing discussion with him about whether or not Mocks are a good idea. Martin's view (I think) is that they expose too much about the implementation and so inhibit refactoring. Our view is that if you have control of your types and define appropriate interfaces, then those interfaces should be abstract enough not to get in the way — except now you should have a cleaner design.

Last week, while pairing with Peter Bell at work, I had both experiences. We reworked some code that only had a "cluster" ⁽¹⁾ test and, true enough, it was easy to change the internals. On the other hand, we were trying to add more behaviour and the tests would have exploded if we'd coded up all the combinations. But the really interesting event (to me, at least) was that a small code change (in formatting) required changes to all the tests because of the knock-on effects. When we went on to break up the Cluster tests into more orthogonal mock-based tests, it was much easier to get full coverage and a better design fell out.

So, my current conclusion is that Cluster tests can be easier to refactor, but that's not the only flexibility that matters. What's most important, however, is to stick to the Tell, don't Ask principle, which is the real key to flexible code.

⁽¹⁾ Many TDD'ers like to work with small clusters of related objects, like a little integration test. They set some initial conditions and check the state of the objects at the end of the test.

Ward joins Microsoft!

Ward has announced that he's joined Microsoft. Given the number of Agile luminaries they've acquired, I'd like to see some early progress from Microsoft in making their products appropriate for Agile Development.

Another reason to avoid writing comments

I've been converting my soon-to-be-ex (1) team to the XP approach to comments (i.e. don't, fix the code instead). We had a problem that really had to have a line of comment to explain it (some hackery to stop Visual Studio complaining). Peter Clary noticed that when there are very few comments, the ones you do have really stand out and attract your attention. Kinda obvious, really, but it's nice to have the reinforcement.

(1) Last day in Thomson Financial on Monday, joining Thoughtworks next year.

P.S. My first post! Finally got around to it...