Liz Keogh, lunivore

After reading Chris Matt’s comments on interfaces, I started noticing all kinds of FooImpl classes in the code over here. As far as I can tell, the only reason for using …Impl for a class name is because the Foo interface only exists to be mocked – so the implementations are FooImpl, MockFoo and any other one-off Foo implementations used in testing.

I like ‘real’ names. I’d prefer to see classes named, say, DefaultFoo or SimpleFoo or BasicFoo instead. FooImpl feels clunky, especially if it’s still there after AdvancedFoo and QuickFoo are created. Is this a good thought, or am I missing something?

These thoughts mostly prompted by reading about PicoContainer, which is cute but seems to promote the naming pattern.

Update: there are better names than DefaultFoo (thanks for anonymous advice)

Lunchtime discussions of the two theories above, what they actually mean, whether they’re meaningful and why the Titanic sank.

Here’s a quick summary of what I learnt, in a vague order:

• There are two different types of system: one which iterates and responds to feedback, and one which anticipates the future based on the past, and ploughs ahead from there. Agile methods fall into the first category.
• If you ask for a definition of agile methods, every person will give you a different answer, except for Chris, who will give you the right answer, and Ade, who will give you the same answer as Chris: “Agile is about delivering Business Value (with Software) through learning via continuous feedback.” (origin)
• The theory of options suggests you shouldn’t exercise your options before you have to. It may say some other things which I haven’t learnt yet.
• The theory of constraints is all about making systems efficient and avoiding bottlenecks. The example used was firefighting. If you have one member of a bucket chain who’s faster than everyone else, he’ll pass buckets as soon as he gets them. The result will be that the guy next to him ends up dropping buckets and spilling some of the water. The system becomes more efficient when you slow the down the speed-freak. Similarly, a system is efficient when the production line moves at the same speed all the way through, preferably producing single items at a time and avoiding batches. Batches occur when things pile up.
• A certain British vehicle manufacturer produced too many vehicles, overestimating the demand. The vehicles piled up and the Brits ran into trouble. A certain Japanese vehicle manufacturer produces cars to customer specifications, and concentrates on reducing the time from order to delivery. Guess which one’s most Agile.
• There are lots of reasons why the customer pull won’t work on some systems. Agile has come about because the future can’t be foreseen in software, so the iterative process takes over.
• Did the Titanic sink because a) the Brits didn’t use enough CFCs in their deodorant, or b) because the hull wasn’t strong enough, or c) because they didn’t have a snazzy radar detector? While it’s true that using more CFCs in deodorant may indeed have melted the iceberg, it’s not the most efficient way of avoiding the accident in future. I reckon it’s due to a lack of communication betweeen the designer, who knew that the ship would sink if a certain number of compartments were breached, and the captain, who thought he was driving an unsinkable ship and drove it too fast, and was therefore unable to avoid the iceberg.
• It’s important to respond to the right kind of feedback. For instance, sacking all the blondes in a company because the project with a blonde on it failed is not always useful.
• They should have had a laser system for destroying icebergs on the front.
• Kate Winslet is annoying.

I’ve just joined the consultancy at which I’ve wanted to work for a while, and thought it might be an idea to use a blog to keep track of discussions, advised reading, things I learn, things I didn’t need to learn, etc. This is not my personal blog, which lies elsewhere.