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
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.
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
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
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
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
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
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