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