Khaos

Archive for October, 2002

Old School Pal Net Works

Tuesday, October 15th, 2002

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

Software Engineering like a Contact Sport

Monday, October 14th, 2002

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

Is Bad Training Better Than No Training?

Sunday, October 13th, 2002

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

Software Reviews

Sunday, October 13th, 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.

Good Error Messages

Thursday, October 10th, 2002

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…

Do You Need to be a Programmer to Manage Programmers?

Wednesday, October 9th, 2002

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

YAPC::Europe Talk

Tuesday, October 8th, 2002

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

Knowing Which Technique To Use

Thursday, October 3rd, 2002

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

What Does It Mean To Be Great?

Wednesday, October 2nd, 2002

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

Fewer Lines Of Code

Wednesday, October 2nd, 2002

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