I once hit a problem whilst developing that meant I could do no productive work for five days. Five days may not seem like a long time but when you only have 13 days to complete an iteration it feels like a lifetime. I was working with a new product and no one on my team had encountered the problem before and I found it very difficult to get support from the vendor who also hadn’t encountered the problem. I don’t remember how I fixed this but I remember how annoyed I was a few weeks later when I discovered that someone else in the company had previously solved the same problem. It turned out that there were three different teams all learning to use the same technology at the same time!

When I spoke to my boss about this communication problem he told me that although the company talked about knowledge sharing from time to time they had never been able to come up with a way to make this work.

I contacted the leaders of the other teams and pointed out that we were all busy struggling with the same things. We were all in agreement that we could benefit from each others mistakes and successes. However, no one could think of a sensible way to pass on the knowledge. All the suggestions we had involved writing documentation and no one had any time in their budget to write these documents. From past experience they also knew that the team members would resent having to write them and that no one would bother to read them.

I left the company not long after this and went away with the impression that knowledge sharing, whilst being a nice idea, didn’t really work in practice.

Tonight I was reading Nancy M. Dixon’s book Common Knowledge in which she discusses the pleasure we feel when we pass useful knowledge to other people.

The truth is that if we know something that we think someone else needs to know, it is difficult for us to refrain from telling them. It is almost a natural impulse to tell others what we know.

So why couldn’t we get people to share knowledge? Well it appears that one reason for this was that we tried to get people to write about their experiences instead of talking face to face. It seems that part of our willingness to share information is to do with the personal benefit we will receive from doing so – even if the benefit is nothing more than a smile or a thank you.

If we want people in our organisations to share what they have learned, we would be wise to create the conditions in which sharing results is of personal benefit

Instead of dreaming up document sharing systems to solve the problem we probably should all have met for pizza once a week and the knowledge would have flowed naturally.

Tony quotes Weinberg.

Under a performance appraisal system, placating or irrelevant managers can think, ‘Well, I won’t bring that up right now. I’ll save it for the performance appraisal in December.’

Before I gave my first performance appraisals I asked my boss if he had any suggestions as to how these should be run. He said, “Nothing that is said at an appraisal should surprise the person who is being appraised”. Good advice.

If the new system can’t be perfect, how can I use it so that it will be better than the one I have now? Improvement is easier than perfection, and as the Chinese say, the best is the enemy of the good.

– Gerald M. Weinberg, The Secrets of Consulting, Chapter 9

The first time you conceive a system based on a requirement, estimating the costs and benefits might be difficult. But, after implementation, you will have a much better idea of the costs and benefits triggered by that requirement.

A well-formulated, measurable, reusable requirement – including a full cost-benefit analysis as part of its description – is every bit as valuable as a reusable software module.

– John Favaro, “Managing Requirements for Business Value”, IEEE Software, vol. 19, no. 2, Mar/Apr 2002, pp. 15-17

If people are unanimously behind a concept, my first instinct is to think there’s something wrong with the concept

– Mark H McCormack, Never Wrestle With A Pig

Mark’s four reasons to be wary are:

1. The concept is too bland
2. People don’t care
3. People don’t get it
4. People are intimidated by the group leader

A while ago Tony quoted Weinberg.

In their desperation, they grasp at anything that’s easily measurable and has some apparent relationship with quality or
productivity.

Again he is talking about managers and the things we like to do to put in our
day. The example he gives is counting the number of lines of code. I don’t
measure this as I don’t believe it is a particularly useful measurement when
writing programs in Perl. However, I have been guilty of measuring things
without having a clear idea as to what meaning the results will give me.

Now I measure the amount of time spent to produce a function. I do this
because I want to improve our estimation process. By comparing actual time
with estimated time I can work out what is really meant by, “that will take me
3 hours”.

I also calculate final project costs. On client based work I use this to decide whether or not the job was completed quickly enough. If it cost us more to produce than the amount we were paid – we took too long to complete the job. What I haven’t been able to do is apply this to internal projects. We always have reasons why the job wasn’t completed within the estimated time and I don’t have enough information to know whether or not it would have been better to either not do the job at all or get someone else to do it for us.

At lunch time today I glanced into a butcher’s shop and noticed that there was sawdust all over the floor. I haven’t seen sawdust on the floor of a butchers since I was a child. As I had no idea why they did this I thought I would look into it. It appears that sawdust is used as a soaking agent and is wonderful for helping you to clean up things like vomit and blood. So, this was put onto the floor to make it easier to clean up the blood that would drip from the carcasses. It was also used by some butchers to make sure that they never sold meat to people that was dropped on the floor.

Everything I read suggested that putting sawdust on the floor was something that butchers did years ago, which makes sense as I don’t recall seeing any dripping carcasses whilst shopping lately. So why do butchers in Belfast still put sawdust on the floor?

That some way of doing things has survived over time does not mean that it is the best way or the simplest way. It may only mean that no one has yet tried to find a better way.

– Edward de Bono, Simplicity

I did my best, it wasn’t much
I couldn’t feel, so I tried to touch
I’ve told the truth, I didn’t come to fool you
And even though
It all went wrong
I’ll stand before the Lord of Song
With nothing on my tongue but Hallelujah

– Leonard Cohen, “Hallelujah”

It took Leonard Cohen more than two years to write that song.

I was reading an interview with Cohen and I was impressed with the amount of effort he puts into writing his songs. Many people talk about songwriting as a mystic art, even Cohen himself.

If I knew where the good songs came from, I’d go there more often. It’s a mysterious condition. It’s much like the life of a Catholic nun. You’re married to a mystery”

Many songwriters, such as Bob Dylan, claim to write songs in about fifteen minutes and talk about songs as flowing from them and coming from a source beyond them. This can lead to the impression that writing good songs is just something that happens spontaneously to gifted people. This isn’t true. Good song writing is both a mixture of inspiration and hard work. Like any other craft it takes years of ground work to produce something special.

Cohen has spent years perfecting his craft. The finished version of “Democracy” contains six verses from the sixty or so that he wrote. This is one of the ones that he discarded as not being good enough.

From the church where the outcasts can hide
Or the mosque where the blood is dignified.
Like the fingers on your hand,
Like the hourglass of sand,
We can separate but not divide
From the eye above the pyramid.
And the dollar’s cruel display,
From the law behind the law,
Behind the law we still obey
Democracy is coming to the U.S.A.

– Leonard Cohen, from an interview published in “Songwriters on Songwriting”

Every occupation has its characteristic diseases. The inability to resist solving problems is only one of the occupational diseases from which consultants suffer. Many consultants pickle their livers at business lunches, blind their eyes on voluminous reports, or bend their spines in endless meetings. But the most serious occupational disease is known as optimitis.

Optimitis can be found in anyone who is asked to produce solutions to problems. It is an inflammation of the optimization nerve, that part of the nervous system which responds to such requests as

“Give us the minimum cost solution.”
“Get it done in the shortest possible time.”
“We must do it in the best possible way.”

In a healthy individual, the optimization nerve responds to such requests and sends an impulse to the mouth to respond,

“What are you willing to sacrifice?”

In the diseased individual, however, this neural pathway is interrupted, and the mouth utters some distorted phrases like,

“Yes, boss. Right away, boss.”

– Gerald M. Weinberg, The Secrets of Consulting, Chapter 2

Friends Reunited now have 7,520,000 registered users of their site with an estimated eight million hits a day.

Software engineering is fundamentally a contact sport. In software engineering as in rugby, no amount of theory about how to succeed in a Scrum is going to come close to real experience in the middle of a few Scrums.

– Barry Boehm, “Software Engineering is a Value-Based Contact Sport”, IEEE Software, vol 19, no 5, Sep/Oct 2002

Tony quotes Jerry Weinberg.

Software reviews are a useful method of on-the-job training. They also greatly improve the quality of code that is produced but not all programmers can or will do it.

Reviews are usually rather clumsy at first, but even without outside help, reviewers soon learn to do a much more efficient and effective job.

Not all programmers make good reviewers. Some programmers make such a bad job of this that you start having to review the reviewers. In my experience the worst type of reviewer is the senior programmer who resents having to waste time looking at other people’s code. They either spend five minutes on the review and pass everything or fail everything with really scathing comments about the stupidity of the developer – neither or these things is helpful to the project or the team.

The company I work for provides Perl training. During the last week I contacted an agency who were looking for someone to deliver a Perl training course in Ireland to a group of people. I asked for details of the specific aspects of Perl they wanted the course to cover and for some idea as to how much they were willing to pay.

Their response astounded me. They wanted to pay about

Why is it so difficult to provide users of a system with decent error messages? Today I renewed my IEEE subscription because I wanted to have access to Software magazine on-line. This proved to be much more difficult than I expected, but after 30 minutes the process was finished. So, I went to the appropriate issue of Software and tried to get access to the article I wanted to read. It didn’t work.

Why didn’t it work? Well the error page I got back said, “You are not authorized to access the service or document you requested”. It gave me more than one reason why this might be the case. If a was a member it was either because I wasn’t an active member or a subscriber, if I was a non-member it was because I wasn’t a subscriber. This was completely unhelpful. There was a link at the bottom of the page to allow me to contact member services. When I clicked on this it took me to a page that said, “We are sorry, the page you have attempted to access was not found on the IEEE web-site…”

Why couldn’t they provide me with more information? I couldn’t work out from the message whether or not they even recognised my user name. Maybe I was typing it in incorrectly. If I was typing it in correctly surely they would have
been able to work out if I was a member or non-member. I went back to the site and tried accessing documents with a made up user name. The message I got back told me that “Your Username and/or Password are not recognized”. Well from this I managed to work out that my user name and password must have been valid.

What I would like is a clear message that tells me as much information as possible, something like:

It was not possible for you to view the requested document because your account has not been valid since September 2002. To renew your subscription please click here. If you have renewed your subscription in the past 24 hours the system will not yet have been updated. If there is still a problem please contact…

Poor management can increase software costs more rapidly than any other factor

– Barry Boehm, Software Engineering Economics

Most people who manage teams of programmers have been programmers themselves. It’s the expected thing. One of the first things I was asked by a team member, when I took over management of a programming team, was whether or not I could do their job. And not only did they expect me to be able to do their job but thought that I should be able to do it better than them because I was getting paid more money.

When I asked why they thought that I should be able to do their job they responded with comments such as:

how will you be able to tell if our code is of good quality;
how will you know if we have spent too long doing a certain job;
how will you have the technical ability to know whether or not it is possible to solve a certain problem?

These questions arose out of misconceptions that the programming team had.

Firstly, they thought that quality was purely about looking at their code and seeing if I liked the way it was written. It never occurred to them, when I first joined, that I would introduce concepts such as software inspection, peer review, best practices for coding and then measure things such as the number of recorded defects introduced by a change to the system, the number of times a new change failed review and the length of time required for this whole process.

They also thought that a manager is someone who is separate from the team. Someone that tells people what to do and how to do it based on how they would have solved the problem themselves in the past.

How would I know whether or not they had spent too long finishing a task? I would ask the programmer at the beginning of a job how long it should take. I would then keep data on the estimates given by staff compared to the actual time taken so that I would have a better idea as to the velocity of the team. I wouldn’t try to guess how long a task should take based on how long it would take me to solve the problem – I wasn’t going to be the person doing the job. The programmers would be telling me when a job took too long.

How will I know whether certain technical problems can be solved? I’ll ask the team. If the whole team tells me the job isn’t possible – then, for all practical purposes, it’s not possible.

Managing software projects is difficult. I don’t believe that my background as a software developer equipped me for managing a team of people.

Programmers who become software managers are prone to a particularly unfortunate failing – they treat people like program components.

– DeMarco & Lister, Software State-Of-The-Art

Finally, only three weeks after I gave the talk, I have finished my paper. Thanks Tony.

When you learn a new technique that greatly improves your productivity, it is hard to see when it does not apply. Usually you learn it within a specific context, often just a single project. It is hard to see what causes the technique to be less effective, even harmful. Ten years ago it was like that with objects. If someone asked me when not to use objects, it was hard to answer. It wasn’t that I didn’t think that objects had limitations – I’m too cynical for that. I was just that I didn’t know what those limitations were, although I knew what the benefits were.

Refactoring is like that now. We know the benefits of refactoring. We know they can make a palpable difference to our work. But we haven’t had broad enough experience to see where the limitations apply

– Martin Fowler, Refactoring

It’s hard to be humble, when you’re as great as I am.

-Muhammad Ali

Death comes to all
But great achievements raise a monument
Which shall endure until the sun grows old.

-George Fabricius

I rarely believe people when they tell me that they are “great” at something. I used to. But after going to hear some of the “great” bands they played with, or seeing some of the code written by a “great” programmers, or being in a car with some “great” drivers I think I became cynical. The real problem is to do with the meaning of the word. It means different things to different people. To me it has a strong meaning. I think to be great at something you need to have a superior skill. You need to be remarkable.

There are lots of people who are good at things, lots of them who are better than everyone else they know but it doesn

The Shopping and Information Service uses microcomputers to improve shopping for the housebound. In specified locations such as local libraries or the Social Services telephone centre the elderly, disabled and others can have their shopping orders entered into a microcomputer. Periodically, batches of orders are transmitted by telephone to the supermarket’s microcomputer for packing a delivery.

Whereas shopping was once a leisurely and personal affair, offering social encounters, the new superstores are clearly part of a trend towards speedy, efficient and impersonal service with most people shopping alone. Shopless shopping may be a dream for the profit hunter, but for the feckless consumer it’s just one more step towards a society in a social vacuum.

Science Now, The High-Tech Supermarket, 1983

Tony comments on software productivity.

If Capers Jones discovered in 1978 that productivity rates decline as the size of the program increases why have we not learnt by now how to make programs smaller? Maybe it

Tony writes about controlling software costs. One of the strategies he mentions for achieving this is writing less code.

I have been trying to think of times when I was encouraged as a software developer to write less code