Less code, more software

Every teardrop is a waterfall

2012-02-09T10:35:00.015Z

I was listening to Coldplay the other day and got to thinking about waterfalls. The classic waterfall diagram is written something like this:

Analysis
    leading down to...
Design
    leading down to...
Implementation
    leading down to...
Testing.

The Testing phase at the end of the process is perhaps the biggest giveaway that something is very wrong. In waterfall, the testing phase at the end is what's known as a euphemism. Or, more technically, a lie. Testing at the end of waterfall is really Debugging. Debugging at the end of the process is one of the key dynamics that prevents waterfall from working. There are at least two reasons:

The first is that of all the activities performed in software development, debugging is the one that is the least estimable. And that's saying something! You don't know how long it's going to take to find the source of a bug let alone fix it. I recall listening to a speaker at a conference who polled the audience to see who'd spent the most time tracking down a bug (the word bug is another euphemism). It was just like an auction! Someone called out "3 days". Someone else shouted "2 weeks". Up and up it went. The poor "winner" had spent all day, every day, 9am-5pm for 3 months hunting one bug. And it wasn't even a very large audience. This 'debug it into existence' approach is one of the reasons waterfall projects take 90% of the time to get to 90% "done" (done is another euphemism) and then another 90% of the time to get to 100% done.

The second reason is Why do cars have brakes?. In waterfall, even if testing was testing rather than debugging, putting it at the end of the process means you'll have been driving around during analysis, design and implementation with no brakes! You won't be able to stop! And again, this tells you why waterfall projects take 90% of the time to get to 90% done and then another 90% of the time to get to 100% done. Assuming of course that they don't crash.

In Test First Development, the testing really is testing and it really is first. The tests become an executable specification. Specifying is the opposite of debugging. The first 8 letters of specification are S, P, E, C, I, F, I, C.
A test is specific in exactly the same way a debugging session is not.

Coupling, overcrowding, refactoring, and death

2012-02-05T12:37:00.024Z

I read The Curious Incident of the Dog in the Night Time by Mark Haddon last week. I loved it. At one point the main character, Christopher, talks about this equation:

P_g+1 = α P_g (1 - P_g)

This equation was described in the 1970s by Robert May, George Oster, and Jim Yorke. You can read about it here. The gist is it models a population over time, a population at generation_g+1 being affected by the population at generation _g. If there is no overcrowding then each member of the population at generation g, denoted P_g, produces α offspring, all of whom survive. So the population at generation g+1, denoted P_g+1 equals α P_g. The additional term, (1 - P_g ) represents feedback from overcrowding. Some interesting things happen depending on the value of α

α < 1: The population goes extinct.
1 < α < 3 : The population rises to a value and then stays there.
3 < α < 3.57 : The population alternates between boom and bust.
3.57 < α : The population appears to fluctuate randomly.

In biological systems each generation has a natural lifespan. The cycle of death naturally helps to reduce overcrowding. But even with the inevitable death of each generation, the system's behaviour is delicately poised. Once α gets into the 3 - 3.57 range the growth starts to outpace the death leading to a rising population, but this leads to overcrowding which reduces the growth leading to a falling population. That reduces overcrowding, and growth rises again. The population repeats in a stable up/down cycle. But only because of the inevitable death. And only while the rate of death is sufficiently high to maintain the cycle. Once α gets beyond 3.57 the rate of death can no longer regulate the increased rate of growth and the system destabilises.

You can think about the process of writing software with this equation.

You can think of over-crowding as being analogous to over-coupling. We feel that a codebase is hard to work with, difficult to live in, if it resists our attempts to work with it. When it resists it is the coupling that is resisting.

You can also think of death as being analogous to refactoring. Just as death reduces overcrowding, so refactoring reduces coupling.

Refactoring is a hugely important dynamic in software development. Without refactoring a codebase can grow without check. Growing without check is bad. It leads to overcrowding. Overcrowding hinders growth.

Incremental development

2012-01-31T16:48:00.005Z

Out of the crisis

2012-01-31T16:26:00.003Z

is an excellent book by W. Edwards Deming (isbn 0-911379-01-0). As usual I'm going to quote from a few pages

All industries, manufacturing and service, are subject to the same principles of management.

Quality comes not from inspection, but from improvement of the production process.

Today, 19 foreman out of 20 were never on the job that they supervise.

Fear amongst salaried workers may be attributed in large part to the annual rating of performance.

Absenteeism is largely a function of supervision. If people feel important to a job, they will come to work.

He that would run his company on visible figures alone will in time have neither company nor figures.

There has never been a definitive study of quality in the dental profession; nor is there likely to be one. Partly because they tend to work alone, dentists resist the idea of being evaluated, or even observed, by others.

Where there is fear, there will be wrong figures.

It is well known that rework piles up: no one wishes to tackle it.

This company had been sending a letter to every driver at every mistake. It made no difference whether this was the one mistake of the year for this driver, or the 15th: the letter was exactly the same. What does the driver who has received 15 warnings, all alike, think of the management?

Cause is effect and effect is cause and vice versa

2012-01-17T10:16:00.003Z

Defects cause lateness.

The more defects code has the more time and effort it takes to get it to done. This seems a self-evident truth. But beware! The Causation Fallacy says it is not easy to know what is cause and what is effect. If a feature misses its deadline pressure often builds to ensure it doesn't miss the next deadline. And under pressure people don't think faster. Extra pressure usually increases the likelihood of defects. This suggests

Lateness causes defects.

So do defects cause lateness, or does lateness cause defects? Or do they rotate around each other like partners on a dance floor?

Sprints, time-boxing, and capacity

2012-01-16T09:04:00.003Z

A team is doing Scrum with 3 week sprints. Suppose at the end of a sprint they've got nothing to done. What should they do? There's a strong temptation to ask for more time. To make this sprint a 4 week sprint. Most of the work in progress is 90% done they say. Another week and things will have got to done, they say. It seems reasonable.

Trying to run systems beyond their capacity is not a good idea. In this situation Scrum's fixed-duration time-box constraint has served it's purpose admirably. The problem is not the choice of 3 weeks. Changing 3 weeks into 4 weeks is not addressing the problem. The problem is the team planned to pull in an amount of work and get it to done in 3 weeks. But they're not yet in control of their process - they don't know what their capacity is. They pulled in more than 3 weeks worth of work. Probably a lot more. But we just don't know!

In The Toyota Way, Jeffrey Liker writes:

Taiichi Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes.

Advice from a genius with a lifetime's experience. Toyota manufactures cars. It makes cars. Its production line is an actual line. If manufacturers are prone to overproduction imagine how much more prone software developers are! The things we make are not even physical things. In software, things are mostly invisible. It's difficult to manage what you can't see. In Quality Software Management volume 2, First-Order Measurement, Jerry Weinberg writes:

Without visibility, control is not possible.
If you can't see, you can't steer.

Rather than asking for another week, the team should really be thinking about addressing their real problem. Their real problem is that they're pulling in too much work. They have to somehow learn to pull in less work. So they can start to be in control of their process rather than their process being in control of them.

Culture quotes

2012-01-14T10:28:00.004Z

I've collected together some culture quotes from previous book snippets:

Culture makes its presence known through patterns that persist over time. (from here)
Jerry Weinberg

Building a culture takes years of applying a consistent approach with consistent principles. (from here)
Jeffrey Liker

Culture makes language, then language makes culture. (from here)
Jerry Weinberg

Culture is what we do when we do not consciously decide what to do. (from here)
Russell Ackoff

Consultants who see culture change as something distinct from the work and, as a corollary, something that can be the subject of an intervention, miss the point. When you change the way work is designed and managed, and make those who do the work the central part of the intervention, the culture changes dramatically as a consequence. (from here)
John Seddon

One aspect of almost every culture is the belief in the utter superiority of that culture. (from here)
Donella Meadows

Culture change is free [because] it's a product of the system. (from here)
John Seddon

Culture is changing faster than it has ever changed before...what once took many generations of gradual development is now attempted by a single individual. (from here)
Christopher Alexander

Hunger is the best source

2012-01-13T09:27:00.008Z

I've previously blogged about being taught ITA spelling at primary school. About how it causes me spelling problems. I was reminded of this when speaking to Geir Amdal at the excellent Agile Coach Camp in Oslo. Geir showed me this wonderful blog post with lovely twist on the famous quote:

Knowledge is power.
Francis Bacon

It reminded me of something my Mum used to say to me when I was little:

Hunger is the best source.

For many many years I didn't understand what she was saying. I was seeing the word sauce as source. She was actually saying:

Hunger is the best sauce.

Food tastes better when you're hungry. Reflecting on my confusion I realize I'm actually quite proud of this mistake. This was a long time ago remember. I was a small boy at the time. Even then, it seems, software was calling me.

Smoking cigarettes, eating sweets, dropping litter, and drinking coffee

2012-01-12T17:37:00.011Z

I was speaking to Olaf Lewitz at the awesome Oslo coach camp last week. We were discussing why drinking coffee doesn't create the same social dynamic as smoking cigarettes. I chatted with Geir Amdal too and quite by chance he mentioned he's given up smoking. And how approaching a work colleague and asking if they want to go outside for a smoke is not the same as asking if they want to go outside for a talk.

Then I remembered something Olve Maudal said to me recently. He said that kids being allowed to eat sweets on Sundays was not really about kids being allowed to eat sweets on Sundays at all. It was really about kids not being allowed to eat sweets on any day except Sunday. Similarly, apparently in the USA when you're driving along you sometimes see a big sign at the side of the road saying "Litter here" and then another sign a mile or so later saying "Stop littering". These signs are also not really about littering. They're about not littering in the places outside the designated littering zones.

There's a crucial difference between smoking and drinking coffee. Smokers tend to smoke in groups in designated areas because smoking is not allowed except in those areas. Coffee is different. Drinking coffee is, by default, allowed everywhere. When you want a coffee you walk to the coffee machine and make a cup of coffee. There's often no one else at the coffee machine so you take your cup of coffee back to your work desk. It is precisely this take-it-back-to-your-desk default which is why there is only rarely someone else at the coffee machine. It is a self-fulfilling dynamic.

If you want to encourage more social interaction between your team members here's what you might do:

Buy machines that make really good coffee.
Put them in a nice area with lots of space to congregate in.
Ban drinking coffee at work-desks.

The third step might seem a bit draconian. But it's vital. You could justify it on the grounds that spilling coffee onto expensive computers will waste money. But the real reason it to encourage developers to drink their coffee near coffee machine. Together. To encourage communication.

My kindle book-case

2012-01-09T12:44:00.012Z

Here's a photo of the kindle I bought myself for Xmas.

When I bought my kindle I forgot to get a case to protect it. I searched around on a few sites looking for a case but didn't find anything I particularly liked. Before I knew it, it was time to head off to the awesome Agile Coach Camp Norway 2012. I wanted to take my kindle but needed a case to protect it. It was too late too order a case via the internet. But I had an idea. I could use a book! A regular old-fashioned hardback book.

I simply cut out a kindle-sized panel from the middle of about 100 pages and then glued the holed pages all together:

Viola, I have a case for my kindle. A book-case you might say.

I showed off my new book-case at the coach camp. It was a hit. At dinner one evening Marc Johnson mentioned he too has a kindle and loves it but misses the social aspect of a real book. The simple fact that most real books display the book's title on its front cover. People can see what you're reading. I sat next to a really interesting man on a plane once. He noticed I was reading Jerry Weinberg's Quality Software Management, vol 2, First-Order Measurement and asked me about it. We chatted away the whole flight.

My kindle book-case allows me to regain this missing social aspect. I can simply print the cover the publishers use for the real book and stick it to the front. So now I have something close to my ideal kindle case. It just needs a clear front cover sleeve so I can easily slide a cover in. And some kind of clasp. As a final bonus, I can pay homage to one of my favourite films:

Managing the design factory

2012-01-05T11:01:00.000Z

is an excellent book by Don Reinersten (isbn o-684-83991-1). This is the second snippet entry for this book (here's the first). It continues my current theme of preferring to re-read a good book many times. As usual I'm going to quote from a few pages:

Whenever we see an intense need for communications it is typically a sign that the system has been incorrectly partitioned.

A complex system can often be built faster when there are stable steps along the way. This is what Nobel laureate Herbert Simon called "stable intermediate forms" in his book The Sciences of Artificial.

We cannot predict the behaviour of a system simply by understanding the behaviour of its components.

There are more possible interactions in a system of 150 components than there are atoms in the universe.

The act of partioning the system is extremely important, because it creates interfaces… these interfaces are both the primary source of value within a system and the primary source of complexity.

The nonlinear behaviour of queueing systems will amplify variability within the system.

We get into an interesting death spiral when we overload our development process. Overloads cause queues; queues, being nonlinear, raise the variability of our process, and variability raises the size of queues.

The weak cross-functional communication of the functional form sacrifices our other economic objectives.

In life, we design most processes for repetitive activities because a process is a way of preserving learning that occurs when doing an activity. … We need to find some way to preserve what we have learned without discouraging people from doing new things.

We get large queues whenever we have large batch transfers in the process.

There is a strong interaction between the design of our organisation structure, our architecture, and our development process.

6000 degree-minutes

2012-01-04T20:38:00.008Z

If you use the same recipe you get the same bread.

That's the White Bread Warning from Jerry Weinberg's truly excellent The Secrets of Consulting.

I was thinking about that the other day and I realized something important. I realized that when I read the word recipe I thought about the ingredients but not really about the non-ingredient related instructions in the recipe. About time. A recipe doesn't just tell you what to mix with what, and in what order, it tells you how long to apply heat. And how much heat. These two things matter just as much as the ingredients. If you change the ingredients you'll get different bread. But if you change the time or the amount of heat you'll also get different bread. Although it might not look much like bread.

Suppose the recipe says to heat the oven to 200 degrees and then cook for 30 minutes. That's 6000 degree-minutes. Now 1200 degrees for 5 minutes is also 6000 degree-minutes. But the bread will be predictably black. Similarly 1 degree for 6000 minutes is also 6000 degree-minutes. But the bread will still be ingredients. Or rather it won't. You see 6000 minutes is 100 hours. Which is 4 days as near as makes no difference. That matters because ingredients are organic. They have a shelf life. A sell-by/eat-by expiry date. They decay. And even if baking the ingredients for 4 days at 1 degree did produce something vaguely bread-like the extra time would create extra cost. In lots of ways. Extra time does that.

Quality software management vol 3, congruent action

2011-12-25T22:40:00.003Z

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-28-5). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

Management is the number one random process element.

If you cannot manage yourself you have no business managing others.

Congruent behaviours are not stereotyped behaviours - quite the contrary. Congruent behaviours are original, specific behaviours that fit the context, other, and self, as required by the Law of Requisite Variety.

Congruence is contagious.

It takes a long time and a lot of hard practice to raise your congruence batting average.

A basic law of perception is that we tend to minimise small differences (tendency toward assimilation) and to exaggerate appreciable differences (tendency toward contrast). Thus, our perceptions make the world more sharply differentiated than it is, and we're a lot more alike than we are different.

The simplest idea about curing addiction is to stop the use of X, under the belief that X causes addiction. X does not cause the addiction, the addiction dynamic causes the addiction.

To change the addiction you'll have to use something more powerful than logic.

One of the manager's primary jobs is to set the context in which interactions takes place and work is accomplished.

Management sets the context almost exclusively through the use of language.

Culture makes language, then language makes culture.

In all Steering (Pattern 3) organisations, the team is the fundamental unit of production.

I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organisations, when I'm not able to be congruent. So I work on that first, and that's what I hope you do, too.

Fit for any type of sea voyage

2011-12-19T16:16:00.005Z

My beautiful wife Natalie met me here in Norway on Saturday. We visited the Viking Ship Museum. One of the displays said:

Et skip som må øses 3 ganger på 2 døgn er sjødyktig til all slags ferd.

which translates as:

A ship that has to be bailed 3 times in 2 days is fit for any type of sea voyage.

I just love that.

Butter sighted at Olve's house

2011-12-18T18:38:00.017Z

This is a photo of a pack of butter belonging to my good friend Olve Maudal. Olve has exactly 157 packs of butter in his house right now. All safely housed in his new super-sized fridge. Many of his 157 packs have been flown in specially by relatives visiting from abroad. Olve would only allow one pack out of the fridge for the photo. Even then he insisted it be taken out under the watchful eyes of the two security guards he's specially hired to guard the fridge - Lars by day and the other Lars by night. Well, you can't be too careful right now. Butter is selling for crazy money on the black (or should that be yellow) market.

Yes, it's just one small example of the butter shortage here in Norway at the moment. Apparently the cause is a new fat-rich fad-diet sweeping the population combined with the seasonal tradition of making butter-rich Xmas cookies.

Shortages like this are, as Stephen Fry might put it, quite interesting. At one point there was probably a very mild shortage. Word of the mild shortage started to spread (sorry) and anyone buying butter bought a few extra packets just to be safe. The shortage got a bit worse. Word of the worsening shortage spread further and faster. People bought even more. A self-fulfilling dynamic was thus set in place. Soon the shelves were stripped of all butter.

The shortage the customers are experiencing is, no doubt, fractally mirrored by the shops selling (or rather not selling) butter. Butter wholesalers just don't have enough butter to meet the orders from shops. Shops that get any butter get less than they ordered. Any butter the shops do get is bought in a flash (but only by relatively few people because of the bulk butter buying behaviour) and they're out of stock again. You can imagine the shop keepers pulling their hair out in exasperation. If only they could get more butter they could make a small fortune. But right when there's the most demand they have none on their shelves! They increase the size of their wholesale reorder hoping to cash in.

What will happen in a few weeks time? One possible (perhaps even likely) outcome, is that the wholesalers will finally get enough butter to meet their over-inflated orders. The shop keepers pile the butter onto their shelves and wait for the Krona to roll in... Some of the butter is sold. But not very much. After all, Xmas is now over. The fat-rich fad-diet has gone the way of all fads and the glossy magazines are now preaching a low-fat diet. And lets not forget that a fair percentage of the population has, like Olve, over 100 packets of butter in their new fridges. They're certainly not going to be buying butter any time soon.

The shop keepers then face the daunting prospect of vast butter-walls sitting unsold on their shelves, fast approaching its sell-by date. Lowering the price doesn't help. It all has to be thrown away. Again the same thing will be fractally mirrored at the smaller scale. Lots of people, such as Olve, will have more butter than they can possibly use in time. They too will have to throw out loads of butter as it goes past its use-by date.

The same lurching from one extreme to another can happen when the number of people trying to make phone calls starts to approach network capacity. People can't get through. So they try again. And when they do get through the line gets dropped. So when they do get through they stay on a bit longer. It happens on roads too.

It's dangerous to run systems at full capacity. They reach a tipping point and topple into a death spiral. Busy work and inventory pile up. That causes even more busy work and even more inventory. But almost no butter is being bought or sold. There is no flow.

Everyday heroes of the quality movement

2011-12-18T09:48:00.002Z

is an excellent book by Perry Gluckman and Diana Reynolds Roome, subtitled From Taylor to Deming : The Journey to Higher Productivity (isbn 0945320078). As usual I'm going to quote from a few pages

Look for the flaws in the system not in each other.

When we reduce complexity, we start to see the organism behaving as a whole rather than a series of parts.

The effects of preventative medicine are hard to measure.

Theories are only the beginning. Why do we find it so hard to exercise, or give up smoking, even when we know all the arguments.

Quality and productivity are results, not goals.

Automating complexity is never as effective as removing it.

I'm not trying to be destructive. I just want to open the doors to some breezes that feel a little chilling to start with.

If there are problems in the company, we don't borrow money. We solve the problems.

If you automate without first getting rid of complexity, you cast the complexity in concrete.

We do almost nothing to control our workers productivity. They are already doing their best without being goaded. What we all try to control is the process itself.

You need to know your financial direction as far as it can be known, and make sure that you don't hit any big rocks. But something else is more important: to design the ship so that it can withstand the blows when they come.

C sequence points

2011-12-09T19:38:00.008Z

Olve Maudal and I created a Deep C/C++ slide-deck recently. It's been downloaded over 300,000 times indicating no small appetite for learning some of the deep secrets of C and C++. So...

In this C fragment z is initialized to the value of n after n += 42 takes place.

if (n += 42)
{
    int z = n;
    ...
}

But how do you know this? For sure? The answer is perhaps not as obvious as you might think. The C standard says:

5.1.2.3 Program execution
(paragraph 2)
Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

In C parlance, n is an object, and n += 42 modifies n. So n += 42 is a side effect. The only thing governing the sequencing of side-effects are sequence points. And there are a lot less sequence points in C and C++ code that you might imagine. There is a sequence point between n += 42 and the initialization of z. But where? And why? The standard says:

6.8 Statements and blocks
(paragraph 4)
A full expression is an expression that is not part of another expression or of a declarator. ... The end of a full expression is a sequence point.

and:

6.8.4 Selection statements
Syntax
selection-statement:
if ( expression ) statement

If we lexically enlarge the expression n += 42 to its left or right we hit the parentheses that form part of the if statement. In other words, the expression stops being an expression and starts to become a statement. That means n += 42 in the fragment is a full expression. That's why there's a sequence point at the end of n += 42. In pseudo code it looks like this:

...
n += 42;
sequence-point
if n != 0 goto __false__;
int z = n;
__false__: 
...

Photo: http://www.noaanews.noaa.gov/stories2005/images/rov-hercules-titanic.jpg

The Toyota Way

2011-11-30T08:25:00.003Z

is an excellent book by Jeffrey Liker (isbn 978-0-07-139231-0). As usual I'm going to quote from a few pages

One day a Ford Taurus mysteriously disappeared. It had been in the factory so they could try fitting it with some prototype mirrors. When it vanished, they even filed a police report. Then it turned up months later. Guess where it was. In the back of the plant, surrounded by inventory.

Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

…was that data was one step removed from the process, merely "indicators" of what was going on.

Building a culture takes years of applying a consistent approach with consistent principles.

It seems the typical U.S. company regularly alternates between the extremes of stunningly successful and borderline bankrupt.

Flow where you can, pull where you must.

When I interviewed [Fujio] Cho for this book, I asked him about differences in cultures between what he experienced starting up the Georgetown, Kentucky plant and managing Toyota plants in Japan. He did not hesitate to note that his number-one problem was getting group leaders and team members to stop the assembly line.

Every repair situation is unique.

The more inventory a company has,… the less likely they will have what they need [Taiichi Ohno]

I posit here that Toyota has evolved the most effective form of industrial organisation ever devised. At the heart of that organisation is a focus on its own survival. [John Shook]

You cannot measure an engineer's value-added productivity by looking at what he or she is doing. You have to follow the progress of an actual product the engineer is working on as it is being transformed into a final product (or service).

Everyone should tackle some great project at least once in their life. [Sakichi Toyoda]

Sense and respond

2011-11-28T15:56:00.001Z

is an excellent book by Susan Barlow, Stephen Parry, and Mike Faulkner (isbn 1-4039-4573-X). As usual I'm going to quote from a few pages

Continuous improvement… is not enough… what is needed also is continuous value creation.

…they continue to create products 'just in case' rather than 'just in time'.

The intelligent business therefore embraces voluntary evolution, designing its own fitness to survive and thrive.

...measure the value creation to value restoration ratio.

Most fast-food burger chains follow, to a large extent, the batch-and-queue principle… Contrast this kind of flow with the one-piece flow achieved by another fast-food company that makes sandwiches and 'subs'… What has been standardised therefore, is not the product but the production method...

Very often the traditional organisation passes work from one department to another in a batch-and-queue system, and with this approach it is not atypical to discover that a task that could be done in ten minutes may actually take ten days to complete. The reason for this is simple: the process is designed that way.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain.

Two options exist for businesses: to make offers to customers or to respond to customers' needs.

Is the customer purchasing an electric drill or holes in the wall?

Adaptiveness… cannot just be added on to an organisation's existing capabilities: the organisation itself must become adaptive.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain. The result is a critical mass of value creation around flow instead of around functions.

Agilis Deliberate Practice

2011-11-24T12:56:00.006Z

Here's the slide-deck I presented at the Agilis conference in Iceland. It contains numerous examples of the kind of improvements a group of developers typically work through in just a few facilitated CyberDojo iterations.

Intention revealing #include ?

2011-11-24T09:41:00.007Z

In a previous post I described how C and C++ have a third #include mechanism. It occurs to me that this idea has possibilities beyond simply using LOCAL(header) as a synonym for "header" and SYSTEM(header) as a synonym for <header> and then using the resulting seam to gain some leverage for testing. You could also add intention revealing names. For example, something like this:

#include "dice_thrower.hpp"
#include <vector>

class stub_dice_thrower : public dice_thrower
{
...
private:
    std::vector<int> stubbed;
};

could be written like this:

#include REALIZES(dice_thrower.hpp)
#include COMPOSES(vector)

class stub_dice_thrower : public dice_thrower
{
...
private:
    std::vector<int> stubbed;
};

Caveat emptor: I don't have any actual examples of this in real code. It's just an idea. It feels a bit like a solution looking for a problem. But I thought I would mention the idea here to see if anyone thinks it has any legs...

Responsibility

2011-11-22T16:05:00.006Z

I had the pleasure of attending the Agilis conference in Iceland recently.

Christopher Avery gave an excellent keynote and spoke about the difference between accountability and responsibility; you are accountable to someone else but responsibility is personal.

He presented his six step ladder of responsibility:

Responsibility
Obligation
Shame
Justify
Lay Blame
Denial

For example, I'm typing this in TextEdit on my Macbook whilst on a train to XP Day. The font is small and my eyesight is fading. For a moment I struggled to discern the tif in the word Justify. I could almost hear a tiny voice inside my head starting to blame. But then I jumped to Responsibility because I realised the fault was not with TextEdit but with me. I simply enlarged the font size.

Christopher handed out a sheet expanding a little on the six step ladder above.

Responsibility is owning your ability and power to create, choose, and attract. It's about your ability to make a response - to respond.
Obligation is doing what you have to do instead of what you want to. As always, if you listen carefully, you can hear this distinction in patterns of speech "… but I have to …".
Justify where we attempt to rationalise the blame, to use excuses for things being the way they are; we make things just in our mind.
Shame is laying blame on oneself (often felt as guilt).
Lay Blame (which is not a French verb ;-) is holding others at fault for causing something.

My son Patrick has Asperger's Syndrome and he has a strong tendency to blame. For example, if he bumps his elbow on the door he gets angry and blames the door. He finds it very difficult to move past this blame, to get inside a positive feedback loop which helps him become less clumsy. So I think laying blame is more than holding other people at fault, it can take the form of blaming anything - anything except oneself.

There is no best practice

2011-11-22T09:23:00.002Z

I had the pleasure of speaking at the Agilis conference in Iceland recently. While preparing my slides on Deliberate Practice I was naturally thinking about the word practice. As far as I can tell, "Best practice" is the most common phrase with the word practice in it. I searched for "Best practice" on goggle and got over 270 million hits. I searched for "Better practices" on google and got a paltry 20 million hits.

Best practice…

focuses on achieving someone else's perfect future state
assumes there is only one best practice
emphasises the noun practice
fits with the waterfall-defined-fixed mindset

Better practises…

focuses on improving your own imperfect present state
assumes there are many possible better practices
emphasises the verb - to practice
fits with the agile-empirical-growth mindset

Float fishing rivers

2011-11-10T08:37:00.000Z

is an excellent (out of print) book by Ken Giles and Dave Harrell (isbn 0-947674-23-3). As usual I'm going to quote from a few pages

I always tend to feed the line off the [closed face] spool by hand.

It is also important, regardless of which brand of line you use, to use them in conjunction with a silicon spray. … it does make a big difference. I always spray it on my spool at the start and even if the wind gets up later on, I find I can still sink the line when I have to and then leave it on the surface again if the wind drops.

If you are fishing a very slow moving river such as the Nene or the Welland, where there is a strong wind, then you need the float to be loaded, because when you cast, it goes into the water like an arrow, completely burying itself and helps you to sink your line without it being pulled away from the far shelf.

Holding back is generally only used after the first frost of winter.

The most important point that must be covered on stick float fishing is the need to keep the line behind the float at all times. This is a must. It just does not work if the line is allowed to go in front of the float.

As a line gets older, it has a greater tendency to sink, so by always having fresh line on your reels this problem is easily overcome.

When I hold back, I do not hold back really hard.

Regardless of the method, be it stick float or wagglier, you must keep changing your depth around between being a couple of feet over depth to a couple of feet below the surface. Also, it is important to keep altering your shooting to find and keep in touch with the fish.

You do not select the float you want, you select the amount of weight you want to reach where you intend to fish and then pick a float to suit that.

I also feel that it pays to feed two lines like this anyway, to allow you to rest one against the other.

When waggler fishing I am ringing the changes far more often than I need to with the stick float.

The worst thing you can do… is to feed out of habit, as opposed to in response to the fish.

I think that work rate is the key to it all.

10,000 warnings

2011-11-09T08:39:00.004Z

Suppose you are working on a codebase that has 10,000 warnings. Perhaps you have discussed how you can get rid of the warnings. Perhaps you have discussed it more than once. But you still have 10,000 warnings. What can you do? There is no magic bullet. You are not going to be able to buy a magic tool, or wave a magic wand, and with almost no effort, get rid of them all. If there was you would already have waved the wand.

Even if there was such a silver bullet it would create a shallow improvement, rather than a deep one. It would create no dynamic whatsoever to encourage the developers to learn how not to introduce warnings in the first place. It would do the opposite.

Naturally new warnings keep appearing. Tomorrow there will be 10,001 warnings. But the 1 new warning gets lost in the sea of 10,000 others. It's not even noticed. The number of warnings is trending relentlessly upwards.

The only way you can get rid of 10,000 warnings is the same way you got them in the first place. A little bit at a time. With effort. Effort that shows you care.

The first thing to do is put a finger in the hole. Cap the number of warnings. Make new warnings count as errors from now on. Don't just say "new warnings count as errors from now on". You said that last time and it didn't work. Actually alter the way you build your software so that new warnings cause a build failure. If module X has 3,663 warnings then 3,663 is the stake in the ground. If it gets more than 3,663 make that a build failure.

This creates pressure to remove warnings on the code actually being worked on. In a culture where warnings are ignored to the extent that they've grown to be 10,000 strong, developers are not likely to see the merits of removing warnings from old code that seems to work and no one has touched for a long time.

Once the number of warnings has stabilized, or even started to trend slightly downwards, you can work on reducing the number of warnings. If the maximum number of warnings in the build is currently 10,000 then set a target. Agree that in a weeks time the number will have dropped to 9,900. Or agree to look at the classes of warnings and target the worst one.

You don't have to get to zero. Getting to zero would mean removing warnings from old code that hasn't been touched for ages. That's not as important as changing the dynamics of the how people act so that the number of warnings is going down rather than going up.

Once you get to a level your happy with, don't turn the build-checks off. Don't take your finger out of the hole. If you do that warnings can easily start to rise again. Leave them in place.

Once you get to a level your happy with, look at ways you can improve further. Buy new tools that detect new warnings. And start again. Focus on improvement not perfection.

#include - there is a third way

2011-11-07T16:35:00.032Z

Isolating legacy code from external dependencies can be awkward. Code naturally resists being isolated if it isn't designed to be isolatable. In C and C++ the transitive nature of #includes is the most obvious and direct reflection of the high-coupling such code exhibits. There is a technique that you can use to isolate a source file by cutting all it's #includes. It relies on a little known third way of writing a #include. From the C standard:

6.10.2 Source file inclusion
...
A preprocessing directive of the form:
  #include pp-tokens 
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. ... The directive resulting after all replacements shall match one of the two previous forms.

An example. Suppose you have a legacy source file that you want to write some unit tests for. For example:

/*  legacy.c  */
#include "wibble.h"
#include <stdio.h>

int legacy(void)
{
    ...
    info = external_dependency(stdout);
    ...
}

First create a file called nothing.h as follows:

// nothing!

nothing.h is a file containing nothing and is an example of the Null Object Pattern). Then refactor legacy.c to this:

/* legacy.c */
#if defined(UNIT_TEST)
#  define LOCAL(header) "nothing.h"
#  define SYSTEM(header) "nothing.h"
#else
#  define LOCAL(header) #header
#  define SYSTEM(header) <header>
#endif

#include LOCAL(wibble.h)  // <--- 
#include SYSTEM(stdio.h)  // <--- 

int legacy(void)
{
    ...
    info = external_dependency(stdout);
    ...
}

Now structure your unit-tests for legacy.c as follows:
First you write the fake implementations of the external dependencies. Note that the type of stdout is not FILE*.

/* legacy.test.c: Part 1 */

int stdout;

int external_dependency(int stream)
{   
    ...
    return 42;
}

Then #include the source file. Note carefully that we're #including legacy.c here and not legacy.h

/* legacy.test.c: Part 2 */
#include "legacy.c"

Then write your tests:

/* legacy.test.c: Part 3 */

#include <assert.h>

void first_unit_test_for_legacy(void)
{
    ...
    assert(legacy() == expected);
    ...
}

int main(void)
{
    first_unit_test_for_legacy();
    return 0;
}

Then compile legacy.test.c with the -D UNIT_TEST option.

This is pretty brutal, but it might just allow you to create an initial seam which you can then gradually prise open. If nothing else it provides a way to create characterisation tests to familiarize yourself with legacy code.

The -include compiler option might also prove useful.

-include file
Process file as if #include "file" appeared as the first line of the primary source file.

Using this you can create the following file:

/* include_seam.h */
#ifndef INCLUDE_SEAM
#define INCLUDE_SEAM

#if defined(UNIT_TEST)
#  define LOCAL(header) "nothing.h"
#  define SYSTEM(header) "nothing.h"
#else
#  define LOCAL(header) #header
#  define SYSTEM(header) <header>
#endif

#endif

and then compile with the -include include_seam.h option.

Fred Foster's Swing Tipping

2011-11-07T11:54:00.001Z

is an excellent (out of print) book by Fred Foster (isbn 0-304-29467-5). As usual I'm going to quote from a few pages

Imagine you are just lifting the hook gently but firmly into the fish and you've got the idea.

As soon as the bomb has settled, I tighten up to it in the normal way and set the swing tip. That's the starting position. I leave the bait there for one minute and then twitch it forward for the first time. ... I give my bait a twitch once every 30 seconds after leaving it for the opening minute.

On hard fished waters, my aim is always to fish as far out from the bank as the prevailing conditions will permit.

As I see it, the hook is always far more visible to the fish when the bait is suspended (as it mostly is with the float) than it is when the bait is on the bottom as it always is when swing tipping.

I prefer a 3 foot hooklength.

In my experience, accurate casting is more vital when swing tipping than in any other form of fishing I have known.

There isn't such a thing as a magic bait and if those who suspected it spent their time practising their tipping instead of wasting it on wild goose chases like this they'd start to give the likes of me a closer run for our money.

Accurate synchronization in the placing of the hookbait in relationship to the feed is one of the most important requirements if you are to achieve any real success.

It's a case of practice makes perfect until you can drop that bomb on the same spot every time.

Quality Software Management. Vol 2. First-Order Measurement

2011-11-06T08:41:00.004Z

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-24-2). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

The update cycle on the project control panel should be scaled to something less than the longest period of time the project can afford to be late.

Large projects always fail when their communication systems fail.

The slowdown of fault removal is a major reason why project times are underestimated.

In the end, it's not the observation that counts, it's the response to the observation. That's why Zen masters teach patience in response.

Culture makes its presence known through patterns that persist over time.

What power corrupts most thoroughly is the ability to make meaning of observations.

Incongruent behaviour is the number one enemy of quality, because it disguises what people truly value.

If you can see it you can review it.

The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 [Routine] to Pattern 3 [Steering].

In my consulting, I frequently talk to managers who seem obsessed with cutting the cost of software or reducing development time, but I seldom find a manager obsessed with improving value.

No other observational skill may be more important to software engineering than precision listening.

Ian Heaps on Fishing

2011-11-05T21:12:00.001Z

is an excellent (out of print) book by Ian Heaps (isbn 0-907675-02-6). As usual I'm going to quote from a few pages

The best way to improve is to practice.

You must feed according to how many fish there are and how they are feeding.

There was a method though, and that was slowing the bait down… the caster needing fishing in a very different way to the maggot.

You must keep it as simple as possible: fish as efficiently as you can.

You must learn to feed on a regular basis so that the fish are charged up, and they get to know exactly when the next amount of food, is going to arrive.

Especially on a river which is flowing, the most important thing is to get a feeding pattern going. Then, there are a thousand and one shooting patterns which will catch them.

If you see the float lifting up a bit when it should be bullying its way through the swim, it is not big enough to do the job.

For me, far too many people are obsessed nowadays with fishing light. All too often they do not experiment and put on enough lead.

Generally speaking, I have found that the more lead you can get on the line and still present the bait properly the more, and the bigger, fish you will catch.

Practice makes perfect, and there is no substitute for experimenting yourself.

If you put on a number of smaller shot and bunch them together, you can soon space them out if the feeding pattern changes.

John [Dean] did the same thing as everyone else - only he did everything just a little bit better.

The lady tasting tea

2011-11-02T19:36:00.002Z

is an excellent book by David Salsburg (isbn 0-8050-7143-2). As usual I'm going to quote from a few pages

It was a summer afternoon in Cambridge, England, in the late 1920s. A group of university dons, their wives, and some guests were sitting around an outdoor table for afternoon tea. One of the women was insisting that tea tasted different depending upon whether the tea was poured into the milk or whether the milk was poured into the tea.

What I discovered working at Pfizer was that very little scientific research can be done alone. It usually requires a combination of minds. This is because it is so easy to make mistakes.

Galton discovered a phenomenon he called "regression to the mean."

The numbers that identify the distribution are not the same type of "numbers" as the measurements. These numbers can never be observed but can be inferred from the way in which the measurements scatter. These numbers were later to be called parameters - from the Greek for "almost measurements."

Bliss invented a procedure he called "probate analysis." … The most important parameter his model generated is called the "50 percent lethal dose," usually referred to as the "LD-50." … The further you get from the 50 percent point, the more massive the experiment that is needed to get a good estimate.

If you are willing to settle for knowing the two parameters of a normal distribution within two significant figures, you need collect only about 50 measurements.

It is better to do mathematics on a chalkboard than on a piece of paper because chalk is easier to erase, and mathematical research is always filled with mistakes. Very few mathematicians work alone. If you are a mathematician, you need to talk about what you are doing. You need to expose your new ideas to the criticism of others.

In the deterministic approach, there is a fixed number, the gravitational constant, that describes how things fall to the Earth. In the statistical approach, our measurements of the gravitational constant will always differ from one another, and the scatter of their distribution is what we wish to establish in order to "understand" falling bodies.

No test can be powerful against all possible alternatives.

In the near disaster of American nuclear power plant at Three Mile Island power plant in Pennsylvania in the 1980s, the operators of the reactor had a large board of dials and indicators to follow the progress of the reactor. Among these were warning lights, some of which had been faulty and presented false alarms in the past. The prior beliefs of the operators were such that any new pattern of warning lights would be viewed as a false alarm. Even as the pattern of warning lights and associated dials produced a consistent picture of low water in the reactor, they continued to dismiss the evidence.

Kolmogorov called a sequence of numbers collected over time with successive values related to previous ones a "stochastic process."

Attitude, passion

2011-10-29T10:22:00.002Z

Attitude is a shop somewhere in an airport terminal in USA. I forget where exactly. Possibly Chicago. Passion is a restaurant in Ghent in Belgium.

The Princess Bride

2011-10-24T17:45:00.001Z

is an excellent book by William Goldman (isbn 0-7475-4518-9). As usual I'm going to quote from a few pages

It's still my favourite book in all the world. And more than ever, I wish I had written it.

This is my favourite book in all the world, though I have never read it.

Miracles. Giants. True love.

Eyes like the sea before a storm.

We are but poor circus performers.

Absolutely, totally, and, in all other ways, inconceivable

Then one morning, Inigo was gone. In his place were three words: "I must learn" on a note pinned to his pillow.

I am not left-handed.

What you do not smell is called iocane powder.

Don't you hurry me, sonny, you hurry a miracle man, you get rotten miracles.

I AM THE DREAD PIRATE ROBERTS AND THERE WILL BE NO SURVIVORS.

Authentic happiness

2011-10-21T17:57:00.001Z

is an excellent book by Martin Seligman (isbn 1-85788-329-2). As usual I'm going to quote from a few pages

Daddy, do you remember before my fifth birthday? From when I was three until when I was five, I was a whiner. I whined every day. On my fifth birthday, I decided I wasn't going to whine any more. That was the hardest thing I've ever done. And if I can stop whining, you can stop being such a grouch.

All emotions about the past are completely driven by thinking and interpretation.

There are, however, no known ways to enhance forgetting and suppressing of memory directly. Indeed explicit attempts to suppress thoughts will backfire and increase the likelihood of imagining the forbidden object.

If you think about bad things in terms of "always" and "never" and abiding traits, you have a permanent, pessimistic style.

Learned optimism… is about accuracy.

Almost nothing that happens to you has just one cause.

Mindful attention to the present occurs much more readily in a slow state of mind.

Total immersion, in fact, blocks consciousness, and emotions are completely absent.

The mood state Americans are in, on average, when watching television is mildly depressed.

The overarching principle of good listening is validation.

By encouraging cheap success, it produced a generation of very expensive failures.

Every drug that breaks up depression also blocks dreaming.

Agile A-Z Keynote

2011-10-14T13:25:00.010Z

I attended the excellent Agile .NET 2011 conference in Ghent, Belgium this week. Jason Gorman pulled out at the last minute and Erik asked me if I'd step in and do the keynote. I said yes of course and prepared this on the train+plane there.

An Agile A to Z

View more presentations from JonJagger.

Waiting work wall

2011-10-13T08:30:00.004Z

One of the things I do a lot when visiting software groups is simply sit with individuals as they work. Sometimes the person I'm sitting next to is a really superb developer. They finish their work fast and to a high standard and hand the work on to the next person downstream. This next person may also be really skilled but their work might just inherently take longer. If the amount of work passed on exceeds the capacity of the next person then a growing batch of work-waiting-to-be-started-by-the-next-person will naturally form and grow.

This batch of work-waiting-to-be-started-by-the-next-person is waste. That's well known and well written about. What's not so obvious and not so well written about is how it encourages silos to form. It literally forms a barrier between the increasingly separated silos that form on either side of it.

Think of each waiting-work-item as a brick in a wall. But not a long, low, queue-shaped wall that's easy to see over. Rather, a short, high wall. One that you can't see over. One that hinders communication.

The amount of waiting-work between two silos is inversely proportional to the lack of communication between the two silos. The more waiting-work, the less the communication. The less communication the more waiting-work. Round and round it goes.

So, if you have some really superb developers then beware. They might be creating a downstream wall of waiting-work around which silos are forming.

Zen in the martial arts

2011-10-12T11:28:00.003Z

is an excellent book by Joe Hyams (isbn 0-87477-101-3). As usual I'm going to quote from a few pages

At least empty your cup and try.

Those who are patient in the trivial things in life and control themselves will one day have the same mastery in great and important things.

The martial artist develops through practice until it becomes mechanical and then spontaneous.

When you lose your temper, you lose yourself - on the mat as well as in life.

The proper system is to think twice more. Patience is part of it. To avoid being intimidated - think more and react less.

Try softer. When one eye is fixed upon your destination, there is only one eye left with which to find the way.

To know and to act are one and the same.

Relaxation and concentration go hand in hand. But too much concentration defeats itself.

Most of the time we generate our own fears, and this is especially true when we confront an unfamiliar situation that shatters confidence.

Years ago I thought too much about what I had to do, laboured over it, put off difficult chores, waited for the mood to be right or the creative juices to flow. Now I just do it without conscious effort. It flows because the work and I are one, and not in conflict with each other.

The only reason men fight is because they are insecure; one man needs to prove that he is better or stronger than another. The man who is secure within himself has no need to prove anything with force, so he can walk away from a fight with dignity and pride.

C will live forever

2011-10-10T10:35:00.004Z

My good friend Olve Maudal said something the other day that caught my ear. He said C will never be replaced. I think he's right. Languages like Java and Ruby are great languages when you don't need to get near to the metal. But if you do need to get near to the metal, then C has already filled that niche so well that it's hard to see it ever being replaced. You might say that a language like C, but without C's penchant for undefined behaviour, could somehow replace C. I don't think so. The point is that the sweet spot for a language designed to be used close to the metal is a language that deliberately does not get rid of its undefined behaviour. Because that is part of it being in the sweet spot. And besides, C has been around long enough that if a language was going to replace C wouldn't it already have happened?

Situated learning - Legitimate peripheral participation

2011-09-29T16:34:00.003Z

is an excellent book by Jean Lave and Etienne Wenger (isbn 0-521-42374-0). As usual I'm going to quote from a few pages

The world carries its own structure so that specificity always implies generality (and in this sense generality is not to be assimilated to abstractness).

Reversing production steps has the effect of focusing the apprentice's attention first on the broad outlines…

The fact that the work was done in an interaction between members opened it up to other members of the team.

There is anecdotal evidence that where the circulation of knowledge among peers and near-peers is possible, it spreads exceedingly rapidly and effectively.

A learning curriculum is thus characteristic of a community.

Understanding and experience are in constant interaction.

Mirroring the intricate relationship between using and understanding artefacts there is an interesting duality inherent in the concept of transparency. It combines the two characteristics of invisibility and visibility… It might be useful to give a sense of this interplay by analogy to a window. A window's invisibility is what makes it a window, that is, an object through which the outside world becomes visible. The very fact, however, that so many things can be seen through it makes the window itself highly visible, that is, very salient in a room, when compared to, say, a solid wall. Invisibility of mediating technologies is necessary for allowing focus on, and thus supporting visibility of, the subject matter.

World class match fishing

2011-09-29T16:14:00.005Z

is an excellent book by Kevin Ashurst (isbn 0-304-29729-1). As usual I'm going to quote from a few pages

I always try to visualise what is happening under the water, and the only concrete clues I can count on are the bites, or the lack of them.

When loose-feeding for roach and dace, it always pays to shuffle the tackle when bites cease. Moving a shot an inch or two, or altering the depth slightly, works so frequently that one has to assume that the fish, as well as becoming wary because of their diminishing numbers, also get shy of baits coming to them in precisely the same way all the time.

Good loose-feeing is one of the key factors affecting success in match angling, and the difficulty of getting it right is one of the reasons why I set so much store by practising for big matches.

The starting point is the knowledge that you cannot scare fish away if they are not there to begin with.

I always think fish behave a bit like birds. If you scatter breadcrumbs on a lawn the birds begin eating it from the edges, rarely alighting in the middle, and I reckon fish behave the same way.

The trick to drop fishing is to read the signs, and the most important one is getting a caster shelled or a maggot sucked without seeing a bite.

A stick float is quite heavy in relation to its size, and at any sort of range we can cop for a splashy sort of strike.

The fish in shallow water tend to be shy. They usually come into the baited area, pick up a bait and bolt.

The original choice of float is obviously dictated by the distance to be cast and the conditions on the day, and the aim should be to achieve whatever distance is required easily. It is better to overcast and pull back than to fall short and have to cast again.

It goes without saying that the kinds of bites we can expect depends entirely on the way the fish are behaving on the day, and how we are shotted in response to that behaviour.

To be perfectly honest the appearance of my floats has never interested me. I never even thought about them in the artistic sense until Colin brought it up, but I suppose the answer lies under the general heading of ignoring everything which is not essential. I devote a lot of time, thought and energy to my fishing, but only to those departments which require time, thought and energy.

More CyberDojos

2011-09-29T14:18:00.013Z

I ran a CyberDojo at the excellent Tampere goes Agile conference recently (left photo). It got a 100% green card vote.

A few days later I ran another CyberDojo for the devs at Solita Oy, also in Tampere. A nicer bunch of people you couldn't ask to meet.

And a few days after that I ran yet another CyberDojo at the Ericsson Agile conference in Helsinki (right photo). @jussikm @htaubert and @karmolis tweeted that it was the most fun they'd had at work in 2011.

ALE CyberDojo Ice Breaker

2011-09-29T14:10:00.006Z

I ran a mass-participation CyberDojo "keynote" at the excellent ALE conference in Berlin recently. 10 laptops were setup with a Yahtzee refactoring exercise in Java. Over 200 people participated. The aim was not to write code - it was to mix people up and get lots of energy into the conference right at the start. I think it worked very well.

We are what we say

2011-09-24T09:01:00.004Z

Steven Fry wrote a piece for Radio Times about his new BBC2 series Fry's Planet Word. The following snippets caught my attention.

Most social groupings of young people have their own private language, catchphrases and nicknames for people and processes.

All that bright individual verbal clothing is put away for the workplace and dull, pretentious verbal suits are worn in their place. Never was the word "suit" less... well... suitable. The memos, meetings and conferences of the workplace are couched in agglomorations of phrases as soulless, bloodless, styleless and depressing as they grey carpets, strip lighting and hessian partitions that constitute their physical environment. Sick-building syndrome is now well understood, sick language syndrome perhaps less so.

We may be what we eat, but we most certainly are what we say.

They reminded me again of the importance of precision listening.

Brain rules

2011-09-21T10:07:00.004Z

is an excellent book by John Medina (isbn 978-0-9797777-4-5). As usual I'm going to quote from a few pages

Students learn better from words and pictures than from words alone.
Students learn better when corresponding words and pictures are presented simultaneously rather than successively.
Students learn better when corresponding words and pictures are presented near to each other rather than far apart on the page or screen.
Students learn better when extraneous material is excluded rather than included.
Students learn better from animation and narration than from animation an on-screen text.

When the brain is fully working, it uses more energy per unit of tissue than a fully exercising quadricep.

Charles Darwin noted… the brains in wild animals were 15 to 30 percent larger than those of their tame, domestic counterparts.

Studies show that a person who is interrupted takes 50 percent longer to accomplish a task. Not only that, he or she makes up to 50 percent more errors.

Spaced learning is greatly superior to massed learning.

A great deal of research shows that thinking or talking about an event immediately after it has occurred enhances memory for that event.

Students are expected to known certain things by certain grades. Curiously absent from this model is how durable that learning remains after the student completes the grade.

When people become sleep-deprived, their ability to utilise the food they are consuming falls by about one-third.

Sleep loss cripples thinking in just about every way you can measure thinking.

Vision is by far our most dominant sense, taking up half of our brain's resources.

All I need to know about manufacturing I learned in Joe's garage

2011-09-17T10:06:00.002Z

is an excellent book by William B. Miller and Vicki L. Schenk (isbn 0-9630439-3-5). As usual I'm going to quote from a few pages

I mumbled back something equally unintelligible, the traditional response to somebody whom you aren't sure you've met and whose name you aren't certain of.

"Why is there such a conflict?" he asked. "Both departments are striving for the same thing, the good of the company. Why should they not work together?"

With all that volume flowing through his "factory," even the slightest unplanned act will ripple through everything else with a domino effect.

Fanatic: A person who redoubles his effort after having lost his direction.

If you double the amount of equipment and tools in use, you must halve the failure rate simply to stay even.

Planning can be perfect - it's all theoretical. Execution can never be perfect - it involves real people using real tools on real material.

People are expected to inspect their own work, both for function and to specification… Statistical and analytical charts are maintained on the production floor by workers, not by Quality Assurance people in a remote office.

Like most computer people would have, he had stayed close to his electronic toy rather than come to the garage to watch the production operation.

The finest carver does the least cutting.

Nobody ever tried harder under pressure.

"know'why" in addition to "know-how"

Long test method names

2011-09-14T12:16:00.006Z

Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch

Writing good code is hard. For lots of reasons. One reason is the tension you try to balance when choosing identifiers. On the one hand you want your identifiers to be longer to give you enough space to make them expressive. But on the other hand you want your identifiers to be shorter so they don't balloon into monsters when combined into expressions. For example:

// too short
bool is_leap_year(int y)
{
    return y % 4 == 0 && y % 100 != 0 || y % 400 == 0;
}

// too long
bool is_leap_year(int intYearValue)
{
    return intYearValue % 4 == 0 && intYearValue % 100 != 0 || intYearValue % 400 == 0;
}

// just right, said Goldilocks
bool is_leap_year(int year)
{
    return year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
}

However, the names of your test methods are not subject to this design tension. The names of your test methods should never be part of a larger expression. So loosen up! Feel free to use long test method names. Names that reflect the specification not the implementation.

// not like this
static void test_leap_year()
{
    assert(!is_leap_year(1999));
}

// like this
static void years_not_divisible_by_4_are_not_leap_years()
{
    assert(!is_leap_year(1999));
    assert(!is_leap_year(2001));
}

THE Secret of Scrum

2011-09-13T16:51:00.007Z

This is another fragment of the ALE conference lightning talk I did. It again follows on from Jerry Weinberg's quote:

No other observation skill may be more important to software engineering than precision listening.

I've tried to become a much better listener in recent years. An active listener. One of the things I've noticed is that software developers are somewhat prone to treat things as being black and white. True or false. Right or wrong. This is perhaps not so surprising for several reasons. Anyway, the point of the clip is not really to poke fun at Scrum, but to highlight the use of the word THE.

Precision Listening

2011-09-13T12:14:00.010Z

At the ALE conference I did a lightning talk. On my first slide I quoted this from Jerry Weinberg's Quality Software Management Volume 1: Systems Thinking:

As consultants, we've found that the quickest and surest way to classify organizations into similar patterns is by the way people think and communicate.

On the second slide I quoted Jerry again (from the same book):

No other observation skill may be more important to software engineering than precision listening.

I was reminded of this a moment ago when someone cold-called me. I honestly don't remember what the person's name was or what they were selling. What I do remember is how the conversation started:

Hello, Jon Jagger speaking.

Hello, can I speak to Jon Jagger please.

Do you recognise this pattern? This response is pure waste. It does nothing but waste my time. After this response the one thing I know for sure is that they're not listening to me. And if they're not listening to me why should I listen to them?

Flow = Speed x Density

2011-09-13T08:59:00.010Z

I attended the ALE conference in Berlin last week. It was excellent in many many ways. Lots of participants have written blog entries and I thought I would write a short one about just one of the many things I thought was really great. It was the above graph which Karl Scotland drew in his talk, The Science of Kanban.

Karl used this graph in the context of traffic.

The green line is traffic Speed and it rises (to the right) from zero at the bottom left.
The red line is traffic Density and it rises (to the left) from zero at the bottom right.
The black line is traffic Flow and equals Speed x Density.

Speaking to Karl afterwards we discussed the analogy:

Speed = cycle time. The time it takes from the moment a piece of work enters the system to the time it gets to Done.
Density = work in progress. The amount of work that has entered the system but hasn't yet got to Done.

Karl also pointed out two feedback loops.

Start on the density line (red) at zero (bottom right) and increase the density (move up and to the left). For a while increasing the density increases the flow. Increasing the flow causes the density to reduce. Thus you have a stabilizing feedback loop helping to increase the flow.
As you continue to increase the density you drop over the top of the flow-curve.
Now as the density increases the flow decreases. And decreasing the flow causes the density to further increase. Thus you have a different destabilizing feedback loop helping to decrease the flow.

Simple and effective. Thank you Karl.

The unknown craftsman

2011-09-03T19:38:00.002Z

is an excellent book by Sōetsu Yanagi (isbn 0-87011-948-6). As usual I'm going to quote from a few pages

The good artist or craftsman has no personal pride.

Seeing relates to the concrete, knowing to the abstract.

To divine the significance of pattern is the same as to understand beauty itself.

A pattern is both true to nature and artificial.

If the material is poor the pattern will suffer.

By and large, good pattern is of communal parentage.

Beauty must have some room, must be associated with freedom.

The Theologica Germanica, written in the fourteenth century, tells is: "He would know before he believeth cometh never to true knowledge". Applied to the perception of beauty, this means that if a man employs the function of knowing before seeing, his power is impaired.

Intuition is the power of seeing at this very moment.

The thing shines, not the maker.

They are made without obsessive consciousness of beauty; thus we catch a glimpse of what is meant by "no-mindedness", whereby all things become simplified, natural, and without contrivance.

Wye Barbel

2011-08-29T14:14:00.007Z

Just back from two fantastic days fishing on the River Wye with my mate Brian on the Wye and Usk Foundation Wyebank and Courtfield beats. He caught this 11 lb'er - a new personal best. We can't wait to go back.

2011-08-29T06:55:00.004Z

is an excellent book by Paulo Coelho (isbn 978-0-7225-3293-5). As usual I'm going to quote from a few pages

"This is the first phase of the job," he said. "I have to separate out the sulphur. To do that successfully, I must have no fear of failure. It was my fear of failure that first kept me from attempting the Master Work.

"But arms cannot be drawn unless they also go into battle. Arms are as capricious as the desert, and, if they are not used, the next time they might not function."

"I had to test you courage," the stranger said. "Courage is the quality most essential to understanding the Language of the World."

"It is not what enters men's mouths that's evil," said the alchemist. "It is what comes out of their mouths that is."

"Tomorrow, sell your camel and buy a horse. Camels are traitorous: they walk thousands of paces and they never seem to tire. Then suddenly, they kneel and die. But horses tire bit by bit. You always know how much you can ask of them, and when it is that they are about to die."

"There is only one way to learn," the alchemist answered. "It is through action."

Quality Software Management. Vol 1. Systems Thinking

2011-08-18T10:28:00.001Z

is an excellent book by Jerry Weinberg (isbn 0-932633-22-6). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

A locked-on system tends to hold itself to an existing pattern, even against logical reasons to change. … Lock-ons occur in clusters.

We particularly look for the degree of congruence between what is said and what is done.

The quickest and surest way to classify organisations into similar patterns is by the way people think and communicate.

The feedback model says you can't successfully control anything for very long without information.

errors - deviations from requirements that give you information to control the system.

The treatment of error as a source of valuable information is precisely what distinguishes the feedback (error-controlled) system from its less capable predecessors and thus distinguishes Steering software cultures from Patterns 1 [Variable] and 2 [Routine].

If the technical reviews are not detecting a lot of mistakes it could mean that … the system is working very well.

Late modules tend to be fault prone modules.

The more modular you make the system, the fewer side effects you need to consider. You trade for this effect by creating modularity faults, or faults in the interaction between modules. You never get something for nothing.

Feedback must operate in small increments, at all levels - personal, product, process, and cultural.

In such a system it is meaningless to ask who is controlling whom?

It's not the event that counts...

2011-08-15T07:00:00.000Z

In Quality Software Management volume 1 Systems Thinking, Jerry Weinberg writes (on page 111)

"It's not the event that counts, it's your reaction to the event".

A bit later, on page 124 Jerry writes something which I've read several times before but for some reason this morning it really spoke to me.

Tools do not determine how they will be used. Therefore it's not the tool that counts, it's your reaction to the tool. Programming tools can be used to program without understanding, or they can be used to free the programmer's mind and hands for tasks that can't be made routine.

Jerry finishes the paragraph with:

Pattern 2 (Routine) managers buy tools to force programmers to work in standard ways. Pattern 3 (Steering) managers manage tools to empower programmers to work in effective ways.

What Did You Say?

2011-08-12T05:59:00.000Z

is an excellent book (subtitled The Art of Giving and Receiving Feedback) co-authored by Jerry Weinberg (isbn 0-924771-33-X). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet. For the past year or so I've deliberately been re-reading books I've already read rather than reading new ones.

Cybernetics tells us that feedback is a relationship between two systems. ... you're a system too.

A lot of our fear of telling them comes from inexperience, or rather experience at giving feedback poorly and then getting a poor result. But getting a poor result is is such a terrible experience only if we have a perfection rule.

Over time, the process of sorting creates an environment that will not provide feedback that leads to change.

In other words, it's not so much the feedback that counts, but the struggle to get it - not the feedback, but the feeding-back.

If you keep doing the same thing why do you expect them to change what they're doing?

Say what you saw and heard.

If mistakes are not acceptable, learning is not possible.

Learning is what feedback is all about.

QCon Deliberate Practice video

2011-08-10T20:52:00.004Z

Videos are like buses. None for ages then two come along at once. I did this talk, on Deliberate Practice at the QCon conference in London earlier in the year (it's only just been put online). It's an extension of my 97 Things Every Programmer Should Know entry.

In the brain of me

2011-08-06T16:10:00.009Z

Here's a video of the SkillsMatter talk I did on Thursday, titled "Stuff I'm starting to know now that I really wish I'd known 20 years ago". Its loosely based on the theme of Making The Invisible More Visible, one of my entries from the book, 97 Things Every Programmer Should Know. I completely botched what I was trying to say about courage. What I was trying to say was that courage is not the absence of fear.

My other SkillsMatter talk was based on Do More Deliberate Practice my other entry in the 97 Things Book.

This was the first run of quite a lot of new material so I was quite nervous, but I felt most of it went very well. Here's some of the feedback.

Fun, informative, useful
An interesting brain dump
Entertaining and enlightening
Very good. Thoughtful and interesting
Great content - very interesting
Great laid back presentation
Interesting ideas and great presentation to go with it
Well planned presentation, not just your standard powerpoint
Very good talk. Inspiring
Very interactive and well explained
Clear explanations, good analogies, funny
Fantastic
Very good. Passionate speaker. Good insights

Becoming a Technical Leader

2011-08-05T12:53:00.002Z

is an excellent book by Jerry Weinberg (isbn 0-932633-02-1). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.

From working with systems, I have learned that the process of change is always organic.

Organic models may be characterized by "systems thinking": the belief that event X is the outcome of hundreds of other factors, including the passage of time.

People improve their performance not by amputating their old behaviors, but by adding new ones.

There are many technical workers who enjoy wandering so much that, like Alice in Wonderland, they don't much care where they go, so long as they get somewhere. Computer programmers call this process "hacking"

In front of each plateau is a ravine.

Probably the most widespread and pernicious myth about leadership is that only Leaders can lead, where the capital L indicates that someone has been appointed to the position of leadership. ... It's only in threat/reward models that leadership and management are synonymous.

You can develop your ability to see and hear more effectively.

People aren't used to thinking in terms of relationships.

I first look for personal power, which can be converted into almost anything.

Break down big learnings into a sequence of little ones, pay attention to the efficiency if your educational strategies, and become aware of your emotional reaction to learning.

CyberDojos

2011-07-30T07:28:00.005Z

I've run a couple more CyberDojo's recently. The first was with Kevlin Henney during an onsite run of our Mastering Agile Practice course for commasoft in Bonn, Germany.

The second was for Mott MacDonald, in Croydon, England. Here's some feedback from the sessions:

an awesome afternoon!
It has been the single most useful training exercises I have attended at motts.
it was an excellent team building exercise and a fun introduction to some development concepts we're not familiar with, in particular pair programming and test driven development, but also the concept of 'deliberate practice'.
helped improve the cooperation within the team
Great!
I want more Dojos

Tests as specifications

2011-07-28T20:18:00.013Z

The other day I was doing the yahtzee kata in C in CyberDojo and I got caught (not for the first time) by a classic gotcha...

I wrote my tests very very simply as follows:


...
static void two_pairs_scored_as_one_pair_is_spots_on_highest_pair(void)
{
    assert(...);
}

static void full_house_scored_as_one_pair_is_spots_on_the_pair(void)
{
    assert(...);
}
...

typedef void test(void);

static test * tests[] =
{
    two_pairs_scored_as_one_pair_is_spots_on_highest_pair,
    full_house_scored_as_one_pair_is_spots_on_the_pair,
    ...,
    NULL,
};

int main(void)
{
    for (int at = 0; tests[at] != NULL; at++)
        tests[at]();
    return 0;
}

I wrote another test and hit the Run-Tests button. But the new test didn't get run because I'd forgotten to add the name of the function to the tests array. Ooops. The new test compiled ok, and I'd tripped up thinking the test was passing when it wasn't even being run.

I've practised in CyberDojo enough that I don't get "sucked into the code" as much as I used to and when something like that happens there's now a fair chance I'll have enough awareness to notice it as it happens.

I stopped and thought about what had happened for a moment and I realized something. My problem was that I was writing the test function definition first. I should be writing the name of the test in the tests array first. And only once I've done that should I define it. There is a nice echo of the idea of Test First Design to this.

Of course in a language with reflection you only need to write the test function. Be that as it is, I like the the way the contents of the tests array lists the function names as specifications. In a language with reflection you don't get that.

The Secrets of Consulting

2011-07-27T10:37:00.001Z

is an excellent book by Jerry Weinberg (isbn 0-0-932633-01-3). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.

Consultants deal in change.

Consulting is the art of influencing people at their request.

..there is the problem of balancing certainty now versus uncertainty in the future.

Consultants are less adapted to the present situation, and therefore are potentially more adaptable.

The toughest problems don't come in neatly labelled packages. Or they come in packages with the wrong labels.

The bigness is not the horse.

The true expert can see multiple aspects of a situation, but the novice sees only... whatever is most conspicuous.

We all know that things tend to fall between cracks and that cracks occur at boundaries, where one system joins another.

For a trigger to be effective, the timing must be perfect: Too late means you're already committed to the troublesome action, while too early means you may forget again betwixt the cup and the lip.

There are always opportunities to jiggle.

Six memos for the next millenium

2011-07-26T09:41:00.002Z

is an excellent book by Italo Calvino (isbn 0-099-73051-0). As usual I'm going to quote from a few pages

Lightness for me goes with precision and determination, not with vagueness and the haphazard... (One should be light like a bird and not like a feather)...

... even correctness of style is a question of quick adjustment, of agility of both thought and expression.

... each value or virtue I chose as the subject for my lecture does not exclude its opposite.

Poetry is the great enemy of chance, in spite of also being a daughter of chance.

On folio 265 of the Codex Atlanticus, Leonardo begins to jot down evidence to prove a theory of the growth of the earth. After giving examples of buried cities swallowed up by the soil, he goes on to the marine fossils found in the mountains and in particular to certain bones that he supposes must have belonged to an antediluvian sea monster. At this moment his imagination must have been caught by a vision of the immense animal as it was swimming among the waves. At any rate, he turns the page upside down and tries to capture the image of the animal, three times attempting a sentence that will convey all the wonder of that evocation.

It is useless at every circle to invent a new form of metarepresentation.

What tends to emerge from the great novels of the twentieth century is the idea of an open encyclopedia, an adjective that certainly contradicts the noun encyclopedia, which etymologically implies an attempt to exhaust knowledge of the world by enclosing it in a circle.

There is a type of work that, in the attempt to contain everything possible, does not manage to take on a form, to create outlines for itself, and so remains incomplete by its very nature.

... the collection of objects of which only one specimen exists.

The classical author who wrote his tragedy observing a certain number of known rules is freer that the poet who writes down whatever comes into his head and is slave to other rules of which he knows nothing.

Synectics

2011-07-25T09:15:00.001Z

is an excellent book by William J.J. Gordon (isbn 978-0060324308). As usual I'm going to quote from a few pages

The word Synectics, from the Greek, means the joining together of different and apparently irrelevant elements.

Abstraction breeds more abstraction and more generality instead of leading to tough yes-no tests.

Words like intuition, empathy, and play are merely names put to complex activities in the hope that the naming of the activity will in fact describe it.

Human beings are heir to a legacy of frozen words and ways of perceiving which wrap their world in comfortable familiarity.

Synectics theory agrees with the conviction that a man does not know even his own science if he knows only it.

"All the crappy solutions in the world have been rationalized by deadlines."

He refused to recognize the fact that his search for the perfect problem was a way of avoiding failure in solving a less perfect one.

Invention is akin to painting for in practice, the element being constructed has the capacity to tell the builder what the next step should be. In invention this is much more critical than in engineering because the inventor is always attempting to do something new.

When this forgetfulness is formalized into a methodology, it reinforces the rejection of the commonplace.

Organic functions are unfinished, cylical, and self-reproductive... Synthetic functions are complete and more obviously subject to decay.

Conventions as abstractions from reality constitute a virtually complete and unassailable pattern, whereas the commonplace is infinitely repatternable.

The child who asks: "What's that funny noise?" is told the noise is thunder in such a way that speculation is supposed to stop... But naming the noise does not describe it. It does not answer the question, it kills it.

Why do car drivers brake?

2011-07-22T07:25:00.008Z

Recently I wrote a small blog entry Why to cars have brakes? It's getting a lot of hits. Well, a lot for me. So naturally in my quest for even more hits here's a follow up...

Imagine you're in a car. Driving along. Why do you brake? I'm not asking what happens when you press the brake pedal? That's too easy (the car stops). I'm asking why…?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Here are two reasons:

Reason one: because there's danger ahead

This corresponds to a failing test. More specifically, it's when a test runs and asserts. A red. Perhaps there's a queue of traffic ahead (often a problem on the orbital car park known as the M25). Perhaps the road is closed off because workmen are working on it. Or maybe the local council has been meddling and the road is now a one-way-but-not-the-way-you-want-to-go road. Whatever the reason, something is not as expected.

Reason two: because you've arrived!

This corresponds to a passing test. A green. Wherever it is you're going, you've got there. Nothing unexpected happened. No traffic queues. No closed off roads. No meddling local council. Incredible!

In my entirely unscientific sampling almost everyone answers with the first reason. The second reason is not nearly as common. I find this interesting. I think maybe it's a reflection of the thinking statically vs thinking dynamically thing again. A perception that tests are most useful when they fire red. That tests which run to completion without incident are not so useful. But they are. Maybe more so.

Brakes help me stop. And stopping implies I'm already moving - I'm already going somewhere. But where? If I don't know where I'm going why am I moving at all? If I don't know where I'm going I'm just as lost as if I don't know where I am.

Tests are useful not just because of the I-didn't-arrive effect when they fail, they're also useful because of the I-did-arrive effect when they pass.

Another reason passing tests are really useful is the elves. But the elves will have to wait for another time.

Peopleware

2011-07-21T06:03:00.003Z

is an excellent book by Tim Lister and Tom DeMarco (isbn 0-932633-43-9). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.

Development is inherently different from production.

The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted. [Tajima and Matsubara]

The manager's function is not to make people work, but to make it possible for people to work.

The trick isn't in the technology; it's in the changing of habits.

An age-old pattern of interior space is one that has a smooth "intimacy gradient" as you move toward the interior.

Employee turnover costs about twenty percent of all manpower expense. But that's only the visible cost of turnover. There's an ugly invisible cost that can be far worse.

It's only the right to be wrong that makes you free.

The structure of a team is a network, not a hierarchy.

Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent.

The more you improve the way you go about your work, the harder the work will be.

The manager of a large project in Minneapolis has refused to move his people to the new quarters. ("New in this case just meant smaller and noisier.) Administrators were simply stunned at his refusal; they had never considered the possibility.

Motivation supplements

2011-07-18T14:58:00.005Z

Just one more thing

2011-07-15T14:57:00.003Z

is an excellent book by Peter Falk (isbn 978-0-099-50955-4). As usual I'm going to quote from a few pages

My object is to keep you awake.

I didn't stay in college the full four years. I quit after three months and joined the Merchant Marine. Men with one eye were not drafted and in the Merchant Marine they were not allowed to work on deck or below deck, but they could work in the kitchen. I sailed out as third cook. My specialty was pork chops.

About the third time I was late, even before I hit my seat, LaGallienne froze me with a question: "Why are you always late?" I said I had to drive down from Hartford. She asked coldly, "What do you do there? There are no theatres in Hartford. How do you make a living?" I told the truth. "I'm not an actor." She snapped back "Well you should be, now sit down."

I remember vividly that particular performance when for the first time I was suddenly startled by a new totally unexpected sound - a rich, deep authentic snore. Holy jamolies. There is someone on this stage that is sleeping - really sleeping.

I have never been arrested in the United States but I have been arrested in Paris, Moscow, Havana, Genoa, Belgrade, and Trieste.

Did he want to be buried or cremated? His answer to them was brief - "Surprise me."

"Here and there you'll find a raisin."

I was struck very early by the dramatic possibilities of playing a man who housed within himself two opposite traits.

For me The Princess Bride was a movie without a blemish, perfect for both kids and adults.

An Introduction to General Systems Thinking

2011-07-15T07:37:00.002Z

is an excellent book by Jerry Weinberg (isbn 0-932633-49-8). As usual I'm going to quote from a few pages.
I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.

The average scientist is good for at most one revolution.

"Proof" in its original sense was a test applied to substances to determine if they are of satisfactory quality... Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities...

They know "better" - which is to say that their illusion is stronger.

We drive more slowly at night to give us more time to observe potentially dangerous situations.

More probable states are more likely to be observed than less probable states, unless specific constraints exist to keep them from occurring.

Things we see more frequently are more frequent: 1. because there is some physical reason to favor certain states, or 2. because there is some mental reason.

The Axiom of Experience can, like all of our principles, be turned around, to become a definition of what we mean by the word "like": Two things are alike if one in the present can be substituted for one in the past.

a "boundary" may not be infinitely thin, precisely so it can partake of both system and environment. Rather than separating, such a boundary connects.

We can learn, if nothing else, proper caution in our speech, which will inevitably lead to proper caution in our thought...

Test-driven development for embedded c

2011-07-14T07:57:00.004Z

is the title of an excellent book by James Grenning (isbn 978-1-93435-662-3). As usual I'm going to quote from a few pages...

A good design is a testable design.

TDD helps you go faster... Slowing down is exactly what is needed to go fast!

Like TDD, if testing is hard, do it all the time - it gets easier.

Test automation is the gift that keeps on giving.

One test result is worth 1,000 expert opinions [Wernher von Braun]

You get a shot of testability with a portability chaser.

If we can identify a particular code smell, we have a better chance of eliminating the bad smell.

Shifting levels of abstraction should happen for a purpose.

Refactoring should be part of everyday development. It's not on the schedule, and you don't ask for permission to refactor.

The industry norm is for code to incrementally worsen with each change. We need to reverse that.

Dual-targetting, like TDD, has another benefit: it influences your design. Paying attention to the boundaries between software and hardware produces more modular designs.

Why do cars have brakes?

2011-07-07T15:02:00.014Z

I don't remember where I was when Kevlin Henney asked me:

Why do cars have brakes?

but I do remember his answer as a definite light-bulb moment. What's your answer?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A very common answer is

to stop

or some variation thereof. In other words, to brake. It reminds me of the noun-verb thing again. Lights light. Irons iron. Compilers compile. Brakes brake. But that was not Kevlin's answer. Kevlin's answer was:

So you can drive faster.

His answer feels paradoxical which usually means there's a deep truth. Brakes allow you to stop when you want. Brakes allow you to stop where you want. Software tests are like brakes. They help you drive faster.

I'm also reminded of the P.W.Bridgman quote at start of chapter 6 of Jerry Weinberg's Introduction to General Systems Thinking:

...it is better to analyze in terms of doings or happenings than in terms of objects or static abstractions.

Thinking about brakes allowing you to stop is thinking statically. Thinking about braking allowing you to drive faster is thinking dynamically.

If you liked this post you might like the follow up Why do car drivers brake?.

A singleton refactoring

2011-07-06T11:48:00.012Z

Here's a refactoring I often teach. It's particularly applicable if you're wanting to refactor legacy code. I'll show it in C++ in honour of the excellent developers at Promethean.

I'll start with a typical Singleton:

class singleton
{
public:
    static singleton & instance();
    void f(int value);
    int g(const std::string & path);
private:
    singleton();
    ~singleton();
};

Together with typical piece of client client code that I'm wanting to unit-test:

int client::eg1()
{
    stuff();
    more_stuff();
    int r = singleton::instance().g("Hello world");
    return yet_more_stuff(r);
}

My problem is that singleton leads to one or more external dependencies I'd like my unit-tests to bypass. My first step is to create an interface for the singleton:

class singleton_interface
{
public:
    virtual void f(int value) = 0;
    virtual int g(const std::string & path) = 0;
    ...
};

And then make singleton implement the interface. (The saving grace of singleton is that its methods are at least instance methods.)

class singleton : public singleton_interface
{
public:
    static singleton & instance();
    void f(int value);
    int g(const std::string & path);
private:
    singleton();
    ~singleton();
};

Now I can overload eg1 as follows:

int client::eg1(singleton_interface & instance)
{
    stuff();
    more_stuff();
    int r = instance.g("Hello world");
    return yet_more_stuff(r);
}

int client::eg1()
{
    return eg1(singleton::instance());
}

And finally, I can create singleton_interface sub-classes and use them in my unit-tests:

struct my_mock_singleton : singleton_interface
{
    explicit my_mock_singleton(int g_result) 
        : g_result(g_result) 
    {
    }
    void f(int value) 
    {
    }
    int g(const std::string & s) 
    { 
        return g_result; 
    }
    int g_result;
};

void test_client_eg1_hitch_hiker_is_42()
{
    assert(42 == client().eg1(my_mock_singleton(6*9)));
}

Micro refactoring - from here to there

2011-06-29T07:31:00.007Z

One of my Mastery book snippets from a few days ago reads:

Masters ... are zealots of practice, connoisseurs of the small, incremental step.

I was doing the roman numerals kata in ruby and something related to small incremental steps occurred to me. Here's three tests:

def test_to_roman
  assert_equal "I", to_roman(1)
  assert_equal "II", to_roman(2)
  assert_equal "III", to_roman(3)
end

and here's the first code snippet:

def to_roman(n) 
  roman = ''
  if n == 3
    roman = 'III' 
  end
  if n == 2
    roman = 'II'
  end
  if n == 1
    roman = 'I'
  end
  roman
end

I can refactor these three if statements into a single while statement, in very small steps, as follows:

def to_roman(n) 
  roman = ''
  if n >= 3
    roman += 'I'
    n -= 1
  end
  if n >= 2
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1 
  end
  roman
end

and then:

def to_roman(n) 
  roman = ''
  if n >= 1
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1 
  end
  roman
end

and then:

def to_roman(n) 
  roman = ''
  while n >= 1
    roman += 'I'
    n -= 1
  end
  roman
end

Ok. Now here's the original again:

def to_roman(n) 
  roman = ''
  if n == 3
    roman = 'III'
  end
  if n == 2
    roman = 'II'
  end
  if n == 1
    roman = 'I'
  end
  roman
end

And this time I refactor in a different direction, towards an array lookup:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[3]
  end
  if n == 2
    roman = units[2]
  end
  if n == 1
    roman = units[1]
  end
  roman
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[n]
  end
  if n == 2
    roman = units[n]
  end
  if n == 1
    roman = units[n]
  end
  roman
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[n]
  end
  if n == 2
    roman = units[n]
  end
  if n == 1
    roman = units[n]
  end
  roman
  units[n]
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  units[n]
end

In this case I can refactor from a sequence of if statements in two directions equally easy - towards a while or towards an array lookup. Ok. Now consider the situation if I was starting from a switch instead of a sequence of ifs:

def to_roman(n) 
  case n
  when 3 then 'III'
  when 2 then 'II'
  when 1 then 'I'
  end
end

From this I can easily refactor towards an array lookup but refactoring towards a while is perhaps not quite so straightforward.

I'm suggesting that a construct is useful not just in it's own right but also in relation to all the other constructs it might get refactored to or from. How easily can I move from one construct to another? Do some constructs live only on one-way roads? Do some lead you down more dead-ends than others?

I'm reminded of the family on holiday in the West Country who got thoroughly lost. Spotting a farmer leaning on a gate they stop the car, wind down the window and ask

Excuse me. Can you tell me how to get to Nempnett Thrubwell?

The old farmer looks at them and says

Well.... you don't want to start from here.

Test-gunpowder-pudding driven development

2011-06-28T07:59:00.015Z

I was rereading chapter 3, Systems and Illusion in Jerry Weinberg's excellent An Introduction to General Systems Thinking yesterday. On page 56-57 Jerry writes:

If I say: "The exception proves the rule" in front of a large class, there will be a division in understanding... Some will believe I have uttered nonsense, while others will understand "The exception puts the rule to the test"

I've read the book four times. I'm a slow learner but this time something clicked and I immediately understood the earlier passage:

...the exception does not prove the rule, it teaches it.

Jerry goes on:

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

I was struck by two thoughts when I read this. One was the parallel with testing. Of a test as a proof. The other was the word original. I realized that when I hear the word "proof" I have a strong association with its noun meaning rather than its verb meaning. I tend to think of a proof as a finished proof that completely proves something. It's the noun-verb thing I've blogged about before. I wondered if there were any old dictionaries online so I could get a feel for how the generally accepted meaning of the word proof might have changed over time. There is. http://machaut.uchicago.edu/websters has two Webster's dictionaries. The 1828 dictionary came back with:

Proof [noun] 1. Trial; essay; experiment; any effort, process or operation that ascertains truth or fact. Thus the quality of spirit is ascertained by proof; the strength of gun-powder, ...

The 1913 one came back with:

Proof [noun] 1. Any effort, process, or operation designed to establish or discover a fact or truth; an act of testing; a test; a trial.

and a modern dictionary http://www.thefreedictionary.com/proof said:

Proof [noun]. 1. The evidence or argument that compels the mind to accept an assertion as true.

I find the difference fascinating. The 1828 and the 1913 definitions define the noun as the process whereas the modern one defines the noun as the evidence resulting from the process.

Jerry continues:

We retain this meaning in the "proofs" of printing and photography, in the "proof" of whiskey, and in "the proof of the pudding." Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities to take on an additional sense: "To establish, to demonstrate, or to show truth or genuineness."

At first I didn't understand the bit about "eliminating the negative possibilities". I think it's partly to do with my ITA spelling at school. But I am persistant. Slowly it came to me. The word that did it for me in...

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

...was the word if. To determine if they are of satisfactory quality. The proof was an act. There was the possibility of failure.

I started thinking about the word proof a bit more. I googled the phrase "the proof of the pudding". If you think this phrase is pretty meaningless then you're right - it's a shortened version of:

The proof of the pudding is in the eating.

Again it's about the possibility of failure. It reminds me of the scene in the film The Cat in the Hat (another film Patrick and I love watching) where the Cat has just made some cupcakes (with the amazing kupcake-inator). He tries one and says:

"Yeuch. They're horrible. Who want's some?"

I love that line. I also googled the word proof as related to alcohol content. The history behind the phrase is just wonderful. In the 18th century spirits were graded with gunpowder. Imagine you're buying some spirits. How would you know if an unscrupulous merchant had watered it down? You couldn't tell just by looking. What they did was pour a sample of the solution onto a pinch of gunpowder. If the wet gunpowder could still be ignited then the solution had proved itself. Don't you just love that?

So let's hear it for pudding and for spirits and for gunpowder and for tests. And for the possibility of failure.

The timeless way of building

2011-06-26T06:09:00.004Z

is an excellent book by Christopher Alexander (isbn 0-19-502402-8). As usual I'm going to quote from a few pages

A thing which has the quality without a name never fit any image exactly. What is exact is its adaptation to the forces which are in it.

The fact is that the elements themselves are patterns of relationships.

Any thing which lives can only be achieved as the end product of a process, whose force takes over and replaces the willful act of creation.

The mastery of what is made does not lie in the depths of some impenetrable ego; it lies, instead, in the simple mastery of the steps in the process, and in the definition of those steps.

How does the pattern language, which exists behind this flux, steer it, and enter into it? It hinges on the close relationship between the process of creation and the process of repair.

As in the organism, there is no sharp difference between the process of construction and the process of repair. Each process of construction helps repair some larger whole, of which it is merely a part. No thing is whole unto itself.

Within this process, every individual act of building is a process in which space gets differentiated. It is not a process of addition, in which pre-formed parts are combined to create a whole: but a process of unfolding, like the evolution of an embryo, in which the whole precedes its parts, and actually gives birth to them, by splitting.

The form of the whole, and the parts, come into being simultaneously.

This can only happen if the design is represented in an utterly fluid medium; it cannot happen in any medium where there is even the slightest resistance to change.

No building is ever perfect.

Yahtzee in ruby in CyberDojo

2011-06-19T12:42:00.004Z

I've been doing the Yahtzee kata in CyberDojo to improve my Ruby. During the 247 increments I learned about...

any?
send
[lo...hi]
reduce
:+
module names start with a capital

It's also on pastie if you like a black background. You can use CyberDojo to step through the diffs of every single increment!

module Yahtzee

  def self.score dice, category, n=nil
    return -1 if invalid(dice, category)
    if category == :value
      value(dice, n)
    else
      send(category, dice)
    end
  end

  def self.chance dice
    dice.reduce(:+)
  end

  def self.yahtzee dice
    dice.uniq.length == 1 ? 50 : 0
  end

  def self.value dice, n
    dice.count{|die| die == n } * n
  end

  def self.one_pair dice
    die(tally(dice).find{|n| pair?n }) * 2
  end

  def self.two_pair dice
    score_tally dice, [2,2]
  end

  def self.three_of_a_kind dice
    score_tally dice, [3]
  end

  def self.four_of_a_kind dice
    score_tally dice, [4]
  end

  def self.full_house dice
    score_tally dice, [3,2]
  end
  
  def self.small_straight dice
    dice.sort == [1,2,3,4,5] ? 15 : 0
  end

  def self.large_straight dice
    dice.sort == [2,3,4,5,6] ? 20 : 0
  end

  #- - - - - - - - - - - - - - - - - - - - - - - 

  def self.categories
    [:value, :chance, :yahtzee, :one_pair, :two_pair,
     :three_of_a_kind, :four_of_a_kind, :full_house,
     :small_straight, :large_straight
    ]
  end

  def self.invalid dice, category
    dice == nil \
      or dice.length != 5 \
        or dice.any?{|die| die < 1 or die > 6 } \
          or !categories.include? category
  end

  def self.score_tally dice, pattern
    starts?(pattern, tallies(dice)) \
      ? sum(dice, pattern.length) \
      : 0
  end

  def self.starts? short, long
    long[0...short.length] == short
  end

  def self.tallies dice
    tally(dice).map{|n| count(n) }
  end

  def self.rolls dice
    tally(dice).map{|n| die(n) }
  end

  def self.tally dice
    dice.uniq.map {|die| [dice.count(die),die] }.sort.reverse 
  end

  def self.sum dice, n
    sum2(rolls(dice)[0...n], dice)
  end

  def self.sum2 scorers, dice
    dice.select {|die| scorers.include?die }.reduce(:+)
  end

  def self.pair? n
    count(n) == 2
  end

  def self.count n
    n[0]
  end

  def self.die n
    n ? n[1] : 0
  end

end

I challenged myself to write the code in a functional style with no local variables - it's a bit 'dense' in places as a result.

Disabling professions

2011-06-18T09:24:00.001Z

is an excellent book by Ivan Illich et al (isbn 0-7145-2510-3). As usual I'm going to quote from a few pages

Finally there is is the American valuation on instrumentalism - an emphasis on doing - on doing something, almost anything when confronted with a problem. "Doing nothing in a difficult situation" was interestingly enough an item diagnostic of neuroticism on a popular American psychological test. Sometimes the emphasis on movement became so great that speed itself was emphasised - sometimes for no logical reason.

It does not strike me as inconsistent, that religion and notions of the hereafter are especially relevant when "the here" is so lousy and so short.

Man has no nature, only a history [Ortega Y Gassett]

there seems to be an absence of informal and comfortable places to gather and talk and thus a further reduction in "informal networks of help".

The business of modern society is service… Thus, service is to care which is to love and love is the universal apolitical value.

The tool defines the problem rather than the problem defining the tool.

There is no greater power than the right to define the question.

The easiest way to create a monopoly is to invent a language and procedure which will be unintelligible to the layman.

When we talk about skilled work it is not the nature of the craft, but the social relation of the worker to management that is under discussion. The full expression of the worker's skill conflicts directly with the needs of management.

One of the real satisfactions of skilled work is that, like an artist, your hands produce what you kind conceives.

The frustration of not being able to apply his skills on the job is often the motivation for doing it at home.

Working effectively with legacy code

2011-06-16T05:07:00.001Z

is an excellent book by Michael Feathers (isbn 0-13-117705-2). As usual I'm going to quote from a few pages

A few years ago, I gave my friend Erik Meade a call after I'd finished work one night. I knew Erik had just started a consulting gig with a new team, so I asked him, "How are they doing?" He said, "They're writing legacy code, man."

To me, legacy code is simply code without tests. I've gotten some grief for this definition… I have no problem defining legacy code as code without tests. It is a good working definition, and it points to a solution.

In nearly every legacy system, what the system does is more important than what it is supposed to do… Frankly, it's very important to have that knowledge of what the system actually does someplace.

When teams aren't aware of their architecture, it tends to degrade. What gets in the way of this awareness? … The brutal truth is that architecture is too important to be left exclusively to a few people.

When you have tests around the areas in which you are going to make changes, they act as a software vise [vice]. You can keep most of the behaviour fixed and know that you are changing only what you intended to.

The most subtle bugs that we can inject are bugs related to inheritance. … The language feature that gives us the most possibility for error when we lean is inheritance.

Orthogonality is a fancy word for independence… One of the startling things that you discover when you start removing duplication zealously is that designs emerge.

Sometimes it makes sense to add a variable to a class and use it to sense conditions in the method that we want to refractor.

…not all behaviours are equal in an application.

Code is pretty fragile material.

At this point in my career, I think I'm a much better programmer than I used to be, even though I know less about the details of each language I work in.

The primary purpose of a compiler is to translate source code into some other form, but in statically typed languages, you can do much more with a compiler.

Mastery

2011-06-14T10:16:00.001Z

is an excellent book by George Leonard (isbn 0-452-26756-0). As usual I'm going to quote from a few pages

You have to be willing to spend most of your time on a plateau, to keep practising even when you seem to be getting nowhere.

Our hyped-up consumerist society is engaged, in fact, in an all-out war on mastery.

Sometimes, when the moment came to go to class, I would be feeling particularly lazy. On those occasions I would be tempted to do almost anything rather than face myself once again on the mat.

Practice, the path of mastery, exists only in the present.

To see the teacher clearly, look at the students… The best teacher generally strives to point out what the student is doing right at least as frequently as what she or he is doing wrong.

A doctor practises medicine and an attorney practises law, each each of them also has a practice.

The master of any game is generally a master of practice.

The courage of a master is measured by his or her willingness to surrender. This means surrendering to your teacher and to the demands of your discipline. It also means surrendering your own hard-won proficiency from time to time in order to reach a higher or different level of proficiency.

The essence of boredom is to be found in the obsessive search for novelty. Satisfaction lies in mindful repetition, the discovery of endless richness in subtle variations on familiar themes.

For the master, surrender means there are no experts. There are only learners.

It can be argued that what is most abstract is most fundamental and often most persistent over time.

Those we know as masters are dedicated to the fundamentals of their calling. They are zealots of practice, connoisseurs of the small, incremental step. At the same time - and here's the paradox - these people, these masters, are precisely the ones who are likely to challenge previous limits.

NDC CyberDojos

2011-06-13T07:29:00.011Z

Last week Olve Maudal and I ran two CyberDojos at the NDC conference in Oslo. The first one attracted only a few people, partly due to some confusion about where it was being held. But what it lacked in quantity it more than made up for in quality. Uncle Bob and Corey Haines seemed to invent a new style of pair programming where Uncle Bob used his left hand and Corey used his right hand! Several people posted encouraging tweets:

@KevlinHenney: If you are at #ndc2011 today, I strongly recommend the CyberDojo with @JonJagger and @olvemaudal this afternoon.
@UncleBobMartin: #ndc2011 CyberDojo was very cool. Too bad you missed it. Must not be very many programmers here
@CoreyHaines: Terrific fun at #cyberdojo at #ndc2010 Only 4 of us there today, you should come to the repeat on Friday after lunch!
@occulto: Best thing today: doing a kata in #cyber-dojo with @sondreb, @unclebobmartin and @coreyhaines #ndc2011 try it on Friday!

More people attended the second one. Corey was there again, along with Michael Feathers and Jon Skeet. Once again the tweets were very encouraging.

In the evening Olve created a TurnKey Linux VirtualBox server image to make it super-easy to run your own CyberDojo. It's less than 500MB and downloadable from http://dl.dropbox.com/u/22404698/TurnKey-CyberDojo-20110610.ova.

Mike Long has written a pdf on how to set it up.

Thankyou to Olve and Mike and to everyone who attended.

Lean on the Compiler by Hiding (C++)

2011-06-10T06:41:00.009Z

My Lean on the Java Compiler by Hiding post has proved quite popular so I've been thinking about if it could also work for C++... It can. I'll use Singleton as a example again. Suppose you have a C++ class like this:

class legacy
{
public:
    legacy();
    void eg1();
    void eg2();
    ...
};

#include "legacy.hpp"
#include "singleton.hpp"

void legacy::eg1()
{
    singleton::instance()->call();
}

void legacy::eg2()
{
    singleton::instance()->call();
}

Again, you want to create a seam for singleton access. The first step is to introduce the hiding identifier in the header file:

class legacy
{
public:
    legacy();
    void eg1();
    void eg2();
    ...
private:
    class singleton;  // <-----
};

Now Lean on the Compiler. All the calls to singleton::instance() no longer compile because the global singleton class is now hidden by the local singleton class just introduced. Next, in the source file add a global variable called instance of type singleton* and refactor all occurrences of singleton::instance() to instance.

#include "legacy.hpp"
#include "singleton.hpp"

singleton * instance;

void legacy::eg1()
{
    instance->call();
}

void legacy::eg2()
{
    instance->call();
}

Then Lean on the Compiler again to make sure there are no typos. Next remove the global variable called instance from the source file and refactor the header file to this:

class singleton; // <-----

class legacy
{
public:
    legacy();
    void eg1();
    void eg2();
    ...
private:
    singleton * instance; // <-----
};

Finally, initialize the instance member in the constructor definition.

legacy::legacy()
    : instance(singleton::instance())
{
}

I haven't tried this on real legacy code either. Caveat emptor!

Lean on the Compiler by Hiding (Java)

2011-06-07T07:11:00.011Z

Here's a small trick which might not be out of place in Michael Feather's excellent book. I'll use Singleton as a example. Suppose you have a class like this (Java):

public class Legacy
{
    public void eg1()
    {
        stuff(Singleton.getInstance().call());
    }
    public void eg2()
    {
        more_stuff(Singleton.getInstance().call());
    }
}

And you want to create a seam for the singleton access. The first step is to introduce two public fields:

public class Legacy
{
    public int Singleton;
    public Singleton instance;

    public void eg1()
    {
        stuff(Singleton.getInstance().call());
    }
    public void eg2()
    {
        more_stuff(Singleton.getInstance().call());
    }
}

Now Lean on the Compiler. All the calls to Singleton.getInstance() no longer compile because the Singleton class is now hidden by the int Singleton just introduced. Next refactor all occurences of Singleton.getInstance() to instance (the other identifier just introduced, you can pick any name for this one but it's type must be Singleton).

public class Legacy
{
    public int Singleton;
    public Singleton instance;

    public void eg1()
    {
        stuff(instance.call());
    }
    public void eg2()
    {
        more_stuff(instance.call());
    }
}

Then Lean on the Compiler again to make sure there's no typos. Finally refactor to this:

public class Legacy
{
    public Singleton instance = Singleton.getInstance();

    public void eg1()
    {
        stuff(instance.call());
    }
    public void eg2()
    {
        more_stuff(instance.call());
    }
}

The name lookup rules for Java allow this to work but I don't think this idea will work in C++ (for example). I haven't got time to try it now as I'm heading off to the NDC conference in Oslo. I only thought of it yesterday. I haven't tried this on real legacy code. Caveat emptor!

Update. I have a C++ version aswell.

Adapt Parameter and Preserve Signature

2011-06-02T09:23:00.011Z

Working Effectively With Legacy Code by Michael Feathers (isbn 0-13-117705-2is a great book. The very first dependency breaking technique (p326) is called Adapt Parameter. It uses this Java example:

public class ARMDispatcher
{
    public void populate(ParameterSource request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put( 
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }
    ...
}

Michael writes:

In this class, the populate method accepts an HttpServletRequest as a parameter. ... It would be great to use Extract Interface< (362) to make a narrower interface that supplies only the methods we need, but we can't extract an interface from another interface. ...

and a bit later...

Adapt Parameter is one case in which we don't Preserve Signatures (312). Use extra care.

Well, here's a variation on Adapt Parameter where we do Preserve Signatures. I'll stick with the Java example, but the idea is broadly applicable...

First we create our ParameterSource interface and fill it with the signatures of the methods in HttpServletRequest that our populate method calls:

public interface ParameterSource
{
    String[] getParameters(String name);
}

then we implement the adapter for HttpServletRequest:

public class HttpServletRequestParameterSource 
    implements ParameterSource
{
    public HttpServletRequestParameterSource(HttpServletRequest request) {
        this.request = request;
    }

    public String[] getParameters(String name) {
        return request.getParameters(name);
    }

    private HttpServletRequest request;
}

Next we add an overload of populate taking a ParameterSource and implement it with an exact copy-paste:

public class ARMDispatcher
{
    public void populate(ParameterSource request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put(
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }

    public void populate(HttpServletRequest request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put(
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }
    ...
}

Now we Lean on the Compiler (315) to make sure we haven't missed any methods in HttpServletRequest that our populate method calls. Add any we missed to the ParameterSource interface. Implement them in HttpServletRequestParameterSource as one liners. When it compiles we can refactor to this:

public class ARMDispatcher
{
    public void populate(ParameterSource request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put(
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }

    public void populate(HttpServletRequest request) {
        populate(new HttpServletRequestParameterSource(request));
    }
   ...
}

And now we have a seam we can pick it at...

public class FakeParameterSource 
    implements ParameterSource
{
    public String[] values;

    public String[] getParameters(String name) {
        return values;
    }
}

I've put together a snippet of the above using CyberDojo

Good luck!

Tao Te Ching

2011-06-01T09:37:00.003Z

is an excellent book translated by R.L.Wing (isbn 0-7225-3491-4). As usual I'm going to quote from a few pages

In trying to understand a work like the Tao Te Ching, it is important to keep in mind that Chinese characters are not so much representations of words as they are symbols of ideas.

Because of its idea-embedded nature, the Tao Te Ching is a work that brings truth to the adage: It is better to read one book one-hundred times than one-hundred books one time.

True power is the ability to influence and change the world while living a simple, intelligent, and experientially rich existence.

Simplicity in conduct, in beliefs, and in environment brings an individual very close to the truth of reality.

When expectations are dropped, the mind expands, and reality expands along with the mind.

Nothing exists without the presence of its opposite.

Practice non-interference.

A house filled with riches Cannot be defended.

Individuals who master themselves become less egocentric

Evolved Individuals strive to be intuitive, spontaneous, and simple.

Never fall completely into step with current society.

Spot the Tao Te Ching Bug

2011-06-01T09:12:00.007Z

Most mornings I read one of the 81 entries in Tao Te Ching . My copy is called The Tao of Power, translated by R.L.Wing. Highly recommended. I use dice together with the chart in the picture (from page 19) to make a random selection. This morning I happened to notice that I never seem to get certain numbers. Closer inspection of the chart shows why...

Pride and revulsion

2011-05-31T15:54:00.007Z

Here's a bug that bit me recently. I wrote a very small quick and dirty TDD header for C in my CyberDojo. It has a macro called CHECK_EQ which you use as follows:

CHECK_EQ(int, 42, 9*6);

Part of the macro looks like this:

#define CHECK_EQ(type, expected, actual) \
    ... \
    type e = expected; \
    type a = actual; \
    ... \

Can you see the problem? Well, suppose it's used like this:

    int e = 42;
    CHECK_EQ(int, e, 9*6);

Can you see it now? The problem is that this line in the macro

    type e = expected; \

gets expanded into this line:

    type e = e; \

Ooops. I thought about choosing a very cryptic name instead of x. Perhaps incorporating __LINE__ as a suffix. But I felt there had to be a solution that would always work. After some thought I came up with this. Brace yourself...

#define CHECK_EQ(type, expected, actual) \
   ...
   if (#expected[0] != 'x') \
   { \
       type x0 = expected; \
       type x1 = actual; \
       ... \
   } \
   else \
   { \
       type y0 = expected; \
       type y1 = actual; \
       ... \
   } \
   ...

Like Tom Duff, I feel a mixture of pride and revulsion at this discovery.

The war of art

2011-05-26T04:27:00.001Z

is an excellent book by Steven Pressfield (isbn 0-446-69143-7). As usual I'm going to quote from a few pages

Every sun casts a shadow, and genius's shadow is Resistance.

The enemy is a very good teacher [Dalai Lama]

The human being isn't wired to function as an individual.

The truly free individual is free only to the extent of his own self-mastery.

Rationalization is Resistance's spin doctor.

Nothing is as empowering as real-world validation, even if it's for failure.

That's when I realized I had become a pro. I had not yet had a success. But I had had a real failure.

The professional knows that by toiling beside the front door of technique, he leaves room for genius to enter by the back.

Whatever you can do, or dream you can, begin it. Boldness has genius, magic, and power in it. Begin it now. [Goethe]

The Self wishes to create, to evolve. The Ego likes things just the way they are.

We humans seem to have been wired by our evolutionary past to function most comfortably in a tribe of twenty to, say, eight hundred.

Kluge

2011-05-25T07:12:00.000Z

is an excellent book by Gary Marcus (isbn 978-0-571-23652-7). As usual I'm going to quote from a few pages

The best science, like the best engineering, often comes from understanding not just how things are, but how else they could have been.

One molecule of DNA polymerase does its job in a perfectly straight-forward fashion, but the other does so in a back-and-forth, herky-jerky way that would drive any rational engineer insane. Nature is prone to making kluges because it doesn't "care" whether its products are perfect or elegant. If something works, it spreads. If it doesn't, it dies out.

What can evolve at any given point in time is heavily constrained by what has evolved before.

The vast majority of our genetic material evolved in the context of creatures who didn't have language, didn't have culture, and didn't reason deliberately.

What is recent is rarely fully debugged.

our memory is organized to focus primarily on our own experiences.

other studies have showed that people are more likely to accept falsehoods if they are distracted or put under time pressure.

organisms tend to value the present far more than the future.

That which is clumsy is rarely reliable.

In physics, they have laws; in biology, we have gadgets [Francis Crick]

The value of imperfections extends far beyond simple balance, however. Scientifically, every kluge contains a clue to our past; wherever there is a cumbersome solution, there is insight into how nature layered our brain together; it is no exaggeration to say that the history of evolution is a history of overlaid technologies, and kluges help expose the seams.

How do you make toast?

2011-05-24T06:40:00.009Z

I'm doing two days consultancy in Cornwall. Yesterday for the folks at Research Instruments in Falmouth and today for the folks at Absolute Software in Redruth. Both are really great places to work and it's a joy visiting them.

I'm staying at the Penventon hotel. My usual breakfast routine is tea, porridge, and toast. They have a big silver toaster. You put your slices of bread into the front, it pulls them in slowly, applies a lot of heat, and then drops them down a shute.

Yesterday they came out mostly black.

I tried scraping them with a knife. I won't bother next time. They never taste good when you do that. All I did was create black dust for someone to waste time cleaning up. They didn't taste good. I didn't eat them.

I was reminded of the joke:

How do you make toast?

You burn bread and scrape the burn off.

Today I put my toast in the same as before. The toaster slowly pulled them in, applied heat, and dropped them down the chute. The slices were under toasted this time. So I put the slices in again. The toaster pulled them in again, applied heat again, and dropped them down the chute again. Just right. No knives. No scraping. No black dust. No cleaning up. I added marmalade. I ate them. Lovely.

Free

2011-05-19T17:29:00.003Z

is an excellent book by Chris Anderson (isbn 978-1-9052-1148-7). As usual I'm going to quote from a few pages

The internet is the first distribution system in history that is as well suited for the niche as for the mass, for the obscure as well as the mainstream.

Just as Moore's Law dictates that a unit of computer processing power halves in price every two years, the price of bandwidth and storage is dropping even faster.

For most of human history manure has determined how much food we had... Historians often look at the great civilizations of the ancient world through the lens of three grains: rice, wheat, and corn. Rice is protein rich but extremely hard to grow. Wheat is easy to grow but protein poor. Only corn is both easy to grow and plump with protein.

Humans are wired to understand scarcity better than abundance.

At some point in your life, you may wake up and realize that you have more money than time.

What [Alan] Kay realized was that a technologist's job is not to figure out what technology is good for. Instead it is to make technology so cheap, easy to use, and ubiquitous that anybody can use it.

Abundant information wants to be free. Scarce information wants to be expensive.

Paradoxes are the opposite of contradictions. Contradictions shut themselves down, but paradoxes keep themselves going, because every time you acknowledge the truth of one side you're going to get caught from behind by the truth on the other side.

Information is what British anthropologist Gregory Bateson described as "a difference that makes a difference."

The electricity consumed by a server now costs more over the life of that server than the server itself.

Rather than depriving life of purpose, material abundance created a scarcity of meaning.

Bounce

2011-05-11T08:06:00.004Z

is an excellent book by Matthew Syed, subtitled The myth of talent and the power of practice (isbn 978-0-00-73505404). As usual I'm going to quote from a few pages

Ericsson also found that there were no exceptions to this pattern: nobody who had reached the elite group without copious practice, and nobody who had worked their socks off but failed to excel.

It is the quality and quantity of practice, not genes, that is driving progress.

The ascendency of the mental and the acquired over the physical and the innate has been confirmed again and again.

My dad never asked me to play golf. I asked him. [Tiger Woods]

Child prodigies do not have unusual genes; they have unusual upbringings.

Top skaters fall over more during their practice sessions.

But while the adaptability of the human body is impressive, it is the plasticity of the brain that has astonished researchers.

If you don't know what you are doing wrong, you can never know what you are doing right.

'These were some of the clearest findings I've ever seen,' Carol Dweck said. 'Praising children's intelligence harms their motivation, and it harms their performance.'

Lowering standards just leads to poorly educated students who feel entitled to easy work and lavish praise. [Carol Dweck]

Many of the contemporaries of Galileo (inventor of the modern telescope) really did think there was something morally dubious about the telescope; that it was taking humanity beyond the powers expressly sanctioned by God.

JavaScript: The Good Parts

2011-05-05T08:08:00.002Z

is an excellent book by Douglas Crockford (isbn 978-0-596-51774-8). As usual I'm going to quote from a few pages

This is not a book for beginners... This book is small but it is dense. There is a lot of material packed into it. Don't be discouraged if it takes multiple readings to get it. Your efforts will be rewarded.

JavaScript's popularity is almost completely independent of its qualities as a programming language.

JavaScript is the first lambda language to go mainstream. Deep down, JavaScript has more in common with Lisp and Scheme than with Java.

strong typing does not eliminate the need for careful testing.

despite its deficiencies, JavaScript is really good.

Unlike many other languages, blocks in JavaScript do not create a new scope, so variables should be defined at the top of the function, not in blocks.

An object is a container of properties, where a property has a name and a value. A property name can be any string, including the empty string. A property value can be any JavaScript value except for undefined.

An inner function also enjoys access to the parameters and variables of the functions it is nested within... This is called closure. This is the source of enormous expressive power.

That act of nothingness gives us confidence that the function does not recurse forever.

What matters about an object is what it can do, not what it is descended from. JavaScript provides a much richer set of code reuse patterns.

Much of the complexity of class hierarchies is motivated by the constraints of static type checking.

var memoizer = function(memo, formula) {
    var recur = function(n) {
        var result = memo[n];
        if (typeof result !== 'number') {
            result = formula(recur, n);
            memo[n] = result;
        }
        return result;
    };
    return recur;
};

var fibonacci = memoizer([0, 1], function(recur, n) {
    return recur(n - 1) + recur(n - 2);
});

Simple and Usable

2011-05-04T08:12:00.000Z

is an excellent book by Giles Colborne (isbn 0-321-70354-5). As usual I'm going to quote from a few pages

If you ask people they'll say everything is important and anything is feasible.

We tend to keep things, even when they're broken.

Your first design may seem like a solution, but it's usually just an early definition of the problem you are trying to solve. Luke Wroblewski.

Broken gets fixed. Shoddy lasts forever. Jack Moffett.

Feature lists sell so as long customers don't get a chance to use the product.

Mainstreamers want "good enough quickly;" experts want "perfect in as long as it takes."

People prefer to be pilots, not passengers.

"Seven plus or minus two." Many psychologists now believe short-term memory may be rather smaller - perhaps just four items.

Simple organization is about what feels good as you're using the software, not what looks logical in a plan.

Designing simple user experiences often turns out not to be about "How can I make this simple?" but rather "Where should I move the complexity?"

The secret to creating a simple user experience is to shift complexity into the right place, so that each moment feels simple.

Don't try to fill your user's mind with your design.

Nudge

2011-05-03T08:12:00.000Z

is an excellent book by Richard Thaler and Cass Sunstein (isbn 978-0-141-04001-1). As usual I'm going to quote from a few pages

School children, like adults, can be greatly influenced by small changes in the context.

There is no such things as a 'neutral design.'

Roughly speaking, losing something makes you twice as miserable as gaining the same same thing makes you happy. In more technical language, people are 'loss averse'... Loss aversion helps produce inertia.

Most teachers know that students tend to sit in the same seats in class, even without a seating chart.

Eating turns out to be one of the most mindless activities we do. Many of us simply eat what is put in front of us.

Social scientists generally find less conformity, in the same basic circumstances as Asch's experiments, when people are asked to give anonymous answers.

On average, those who eat with one other person eat about 35 percent more than they do when they are alone; members of a group of four eat about 75 percent more; those in groups of seven or more eat 96 percent more.

Self-control issues are most likely to arise when choices and their consequences are separated in time.

Even hard problems become easier with practice.

The best way to help Humans improve their performance is to provide feedback.

For most of their time on earth, Humans did not have to worry much about saving for retirement, because most people did not live long enough to have much of a retirement period.

public: footpath

2011-05-02T08:12:00.000Z

You know you know C++ when you see a sign like this and you think, "there's a colon missing after public."

Some rules of thumb

2011-05-01T08:12:00.003Z

Don't rush

I don't think I can put it any better than Jerry Weinberg did when I interviewed him:

Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.

As a self-employed software coach/consultant I get to travel a lot and visit a lot of companies. At the best companies there is a palpable sense of not rushing.

Think team

Software development is all about collaborative learning. I think one of the weakest points of the Agile Manifesto is it's lack of emphasis on teams. The very first word of the four "X over Y" statements is Individuals :-( XP at least takes a firm step beyond programming as an individual activity by mandating pair programming. I look at Sit Together, a practice from XP1 and I think s/Sit/X/. In other words, whatever X is, X Together.

Increase visibility

Software and the process of developing it can be, to paraphrase Douglas Adams, mostly invisible. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing. It's no accident that Kanban boards are as popular as they are.

Things are the way they are because they got that way

2011-04-30T08:12:00.002Z

If you're working on a complex codebase and you're trying to understand the complexity by looking at the codebase then you're looking in the wrong place. That's like the man in Peopleware who loses his keys in a dark street and looks for them in the adjacent street because, as he explains, "the light is better there". A codebase is the way it is because it got that way. Slowly. Over time. If you're looking at the code your looking at the effect and not at the cause. It was the developers that did it!

Things are the way they are because they got that way.

Increase visibility

2011-04-29T08:12:00.000Z

My sister Alix and I were chatting about work-related stupidity we'd imagined and experienced. Strict quotas on how much time you're allowed for going to the toilet for example. Naturally the time-allowed for no 2's would be longer than the time allowed for no 1s. But how would the managers police the quotas? The answer, we realized, was specialist plumbing. Take out the old copper pipes and put in clear perspex pipes instead. Plumb them through the managers office, at eye level. Purpose built hardware probes, available at reasonable cost, would measure the volume of shit. The probes would wirelessly connect to ShitLogger (tm) an app for monitoring the volume of shit against the quotas. To log the logs, as it were.

Recency

2011-04-28T09:37:00.002Z

I've written before that:

Human beings have evolved a very strong association that cause and effect are simple and linear; that cause and effect are local in space and time.

One of example of this is when contestants on Who Wants To Be a Millionaire phone a friend. It's easy to think that the friend could simply watch the program and start trying to find the answer before they're called. They can't. What you're watching happened some time in the past. The program is not live.

Another example is this blog! At the recent ACCU conference several people commented on what a fast reader I was. I often blog three or four book snippets in a week. And I am learning to increase my reading speed. And I do read a lot. But it's an illusion. I have a stock of hundreds of books I've already read and all the best bits from them are already marked. I simply take a book from my shelf and blog the best of its best bits as a book snippet. And then put the book onto the ACCU charity book-stall pile.

Bad captcha

2011-04-27T09:56:00.003Z

I had this yesterday. I doubt any human could read that! As my friend Niklas Bjornerstedt tweeted

captchas are getting so hard to read that only robots will be able to solve them soon

Accu conference charity book stall

2011-04-22T17:48:00.004Z

Once again a big thanks to everyone at the accu conference who took a book and made a contribution to the two charities - Water Aid and The National Autism Society this year. The total raised was a smidgen under £600 which will be split equally. Thanks also to my son Patrick (he has Aspergers Syndrome) for lending me the safe. And thankyou too to several people who brought some books for the stall during the conference. I plan to repeat the stall again in 2012.

Deliberate practice booklist

2011-04-12T17:41:00.001Z

Kevlin and I have just finished the accu pre-conference tutorial. A big thankyou to all the participants. The origin of some of the quotes was a little hard to read as the printed handouts were a little small. Here is a list of the books quoted:

The Fifth Discipline by Peter Senge
Talent is Overrated by Geoff Colvin
Surfing the edge of Chaos by Richard Pascale
Quality Software Management Vol 1: Systems Thinking by Jerry Weinberg
Authentic Happiness by Martin Seligman
Implementing Lean Software Development by Mary and Tom Poppendeick
Switch: How to change things when change is hard by Chip and Dan Heath
Mindset by Carol Dweck
The Princess Bride by Bill Goldman
The Autobiography of Martin Luther King Jr edited by Clayborne Carson