Measure or Listen?

Following are thoughts directed at Managers. This could be a Team Lead, a Technical Manager, a Product Manager, and especially a Process Manager.

Why "especially a process manager"? Because in my experience they often want to measure stuff!

Measuring isn't good or bad. Measuring isn't the only thing to do either and it may not be the first thing to do. In my opinion it is never the first thing to do.

If you are working on a software development team and it is experiencing some difficulty what do you do to get "control" of the situation?

Suppose the code is in a state of thrashing in that one bug fix seems to create new bugs.

What would you do?

Maybe you would do this:
1) Are they doing code reviews? How many of you are doing code reviews before check-in?
2) Are there regression tests? How much code coverage do we have with our tests?
(I will stop here for brevity)

For a process manager does everything have a process solution? If the perfect process is in place and there are failures does it mean that the people are wrong? Just a couple of thought questions.

Now to the point.

If there are problems then ask those that are experiencing the problems what they think the problems are and how they think the problems can be addressed. Listen carefully to their responses.

I have worked on many products where the software's design had reached its limit of usability. This includes software that I myself designed. There comes a time where weaknesses and inefficiencies become grossly apparent and it is time to address the core issues. While working on these products (with very large code bases) I have seen the fixes create new bugs and the code stability thrashes about. In each of these instances I have been asked what is wrong and I have said, "We need time to build a new foundation, the code has become a mess of add-ons and kludges and it is only going to get worse." Most every time the response is, "We do not have time for that. We will do code reviews and have someone start on writing tests to get better coverage." And most every time the thrashing problem does not go away. The thrashing seems to lessen but I propose that it lessens only because less code is being written due to the fact that more time is spent in code reviews and writing regression tests.

Do you have an example where you felt you knew how to address the "real" problem but was never asked? Is it always a matter of improving the process that will make the bugs go away?

Well, some of you are probably saying, "He wants cowboy programming. He never has liked Process Managers and gives them grief whenever he can. He never has worked on a large project with many developers or he would know that process is what holds it all together." Well, say what you may, that is your prerogative and that is what I am doing here!

I still say this, "Listen first." What does listen mean? It means hearing and understanding. Understanding is the key. This key makes it difficult for managers that do not have technical backgrounds for if they do not understand the problem or the proposed solution. How do such know if the suggestion is good or bad? If the manager doesn't understand the technical issues and only understands process then how can the manager do anything but suggest process changes to address every problem?

Listen first. Measure later.

Geoff

p.s. Maybe you have heard, Measure twice and cut once. It is a saying used by carpenters. It doesn't apply to software. Sorry.