ACCU Buttons

Editorial: Need to Unlearn

Like many men I tend to like my old clothes. Unlike many I've
come up with a strategy that helps me enjoy buying new ones: I
clear out the wardrobe; rather ruthlessly I throw away things and
make space. This done I know I need new clothes and can enjoy
buying them.

I need to use a similar strategy when I write articles and
patterns. Sometimes I draft a piece and there is a sentence or even
a paragraph which I really like, maybe it's witty, sarcastic or
makes a subtle side point, or maybe it's an excellent example of
something. So, I edit my draft - and I should mention I do a lot of
editing - and as I edit I keep the chosen sentence. But over time
it doesn't connect as well with what is around it and maybe I have
to rewrite some of the surrounding text to lead up to this one
sentence.

Eventually it becomes clear that this sentence is more of an
obstruction than a support. It has to be chopped out so the rest of
the text can make its point with brevity and clarity. It may be
painful to do - like getting rid of those old clothes - but you're
better off without it.

(Actually, in truth, I usually use the same trick I do with old
trousers. Take them out of the wardrobe and put them to one side
somewhere, usually in a box under the bed. If you don't need it in
the next six months you aren't ever going to need it. So, I find
files on my hard disc with little bits of articles which I never
get around to using.)

The same thing is true in software. Sometimes a piece of code is
so attractive I don't want to lose it - say it's a nifty bit of
template meta-programming, or a well-formed class. No matter how
nifty the code it can still restrain you, sometimes these things
have to go for the greater good.

And it doesn't end with code. In fact, those who study these
things would consider this unlearning. In
the same way that we learn something we sometimes need to unlearn something. A solution that worked well in
the past doesn't work well now. If we continue to rely on
yesterday's solutions we stop ourselves from learning new things,
like clothes our solutions come to look dated and full of
holes.

The software development community could benefit from a bit more
unlearning. While we're pretty good at dreaming up new languages
and methods we're not so good at throwing some old ideas away.
Sometimes our old ideas work to our benefit, they allow us to
quickly diagnose problems and develop solutions because we've seen
the problem before.

On other occasions these very shortcuts work against us. We use
mental models and assumptions that aren't valid for the problem in
hand. Worst of all, we don't always know we're making these
assumptions. When I was an undergraduate I had a lecturer who
always told us to "Document your assumptions." Problem was, I
didn't realise that I was making assumptions. That's one of the
problems we face, unconscious assumptions, how do we know we are
making them?

Sometimes of course there are big red flags telling us to drop
our assumptions. For example, when you change jobs, in a different
company with different people we need to change. Unfortunately it's
too easy to keep fighting the last war, or see our last employer
through rose-tinted spectacles, your new colleagues don't
necessarily want to hear about how good (or bad) the last place
was.

Too often new people are encouraged to "hit the ground running"
when they start a new job - especially if they are in a contract
position. To do this denies employees the time to learn and to
jettison some of the past and make a fresh start.

I've been guilty of this too, my blood starts the boil the
moment I'm introduced to a "project manager", all these assumptions
kick in: all they care about is GANTT charts, they believe
estimates and the waterfall model, they want to divide, rule and
micro-manage. I have to fight these assumptions, ask myself "What
proof is there that this project manager is like this?"

Recognising and changing our assumptions isn't easy. It is
especially hard when you try and do it on your own. Even looking at
data can be confusing, as we tend to see data that supports our
point of view rather than data that refutes it.

Writing in the Financial Times, Carne Ross (2005) described the
how the British and American Governments argued at the UN with the
French and Russian Governments about the 1991-2003 sanctions
against Iraq. The two sides cited the same reports to support their
case. Ross suggests that both sides were not guilty of ignoring the
contradictory evidence, merely that they failed to see it. The
assumptions each side made blinded them to contradictory data, they
could read the words but their meaning was lost.

We often need other people to help us see our own assumptions;
talking problems through helps us understand them and expose our
assumptions. Other people come with their own, possibly different
assumptions and we can all help highlight one another's. But, when
we are locked in confrontation with others we become defensive, to
admit an assumption, let alone change it, would be to give
ground.

The problem of incorrect and unspoken assumptions affects all
aspects of software development: we think we know what the customer
wants, or we think we know what the software design should be, but
sometimes we're wrong. The need to unlearn assumptions is
particularly apparent when it comes to process and literature.

Although it's a great great book I'm getting a bit fed up of
people citing Brooks' Mythical Man Month.
It was written 30 years ago about a project that occurred 40 years
ago. Haven't we moved on a bit?

While there is some great advice in Brooks' work there is some
we need to unlearn. Lets start with "Build one
to throw away, you will anyway." Brooks himself has changed
his mind on this:

" 'Plan to throw one away; you will anyhow.' This I now perceive
to be wrong, not because it is too radical, but because it is too
simplistic.

The biggest mistake in the 'Build one to throw away' concept is
that it implicitly assumes the classical sequential or waterfall
model of software construction."

(Brooks, 1995, p.265)

Then there are Chief programmer teams.
This is the idea that we can have a few great programmers and
arrange things to support them, keep them working productively and
all will be right. This approach leads to teams where several
lesser programmers work individually on minor pieces of
functionality while the Chief or super programmer(s) delivers the real
value. Consciously or unconsciously managers and programmers
believe that Jim the super-programmer will deliver 70% of the
project while his three helpers will deliver 10% each, of course
they'd like four super-programmers but they "can't find them" so
they settle for just reducing the load on Jim.

This is quite the opposite of what many people now think and
flies in the face of what Agile
methodologies advocate. Here - as in much of twenty-first century
modern business life - it is the team that is important. Whether it
is serving fries in McDonalds, building a Nissan or writing
software, simply, the scale of modern endeavours means that it is
the team that is the building block not the individual.

So, it is with dismay that I hear developers and managers
proclaim, "If we only had a few more good people" or "Where can we
get more good people?" It is not the lack of individuals that hold
our developments back but the lack of good, productive, teams.

We need to apply a bit of unlearning here. Let's try and unlearn
this particular mantra.

Sure, maybe one in 100 engineers is more productive than the
other 100 put together but are we right to base our entire
development process around finding this individual? We need to find
them, hire them, motivate them and retain this one person. Even if
we can do all that is it right to base an entire strategy around
this person? And the chances are, one person isn't enough, we're
going to need 10, 20, 100 more like him (and it usually is a him.)
And how do these guys work as part of a team? Usually not too
well.

It could be that our one individual is actually holding the team
back. They may actually block others from dealing with a problem,
or their very productivity may hide a fault with the team. Alistair
Cockburn tells the following story:

"...a consultant who visited his company and said words to the
general effect of, 'If I go into a company and see one
super-salesman who is much better than all the rest, I tell the
owners to fire this man immediately. Once he is gone, all the
others improve and net sales go up'."

(Cockburn, 2003, p.27)

Fact is, the super-programmer approach doesn't scale.

Instead, we need to hire and develop teams of people. We give
them the tools they need to do the job, and we remove the blockages
that stop them from working more productively. We encourage them to
improve themselves, their environment, processes and the company -
and that means we aren't scared to change, whether it be moving
desk or trying a new way of working, we reject the assumption that
tomorrow will be a repeat of today.

If we are to expose assumptions we need to enter into open
dialogue with others - not necessarily people who hold the same
point of view. We need to allow time for this, we need to
understand our goals and share mutual goals. Above all we must be
prepared to unlearn ourselves, if we start with a position to
defend and assumptions we're unwilling to let go of then we aren't
going to get very far.

Simple really. Well simple to say, unfortunately, it's
incredibly hard to do, after our unlearning we need to learn
again.