Timing is everything
The project board recently decided to get some other programmers to do a detailed review a part of the system, after a short review had produced a very critical report.
This isn't easy news to announce. The review is in an area of work where one developer, Bert, has done most of the work, and holds most of the reponsibility. Bert's line manager agreed to tell him, then a week later I would announce the decision at the developer meeting. (Names have been changed.)
Unfortunately at the first meeting only half the news was told. The LM tried to make it sound better than it was, and also was persuaded by some counterarguments the developer raised.
As soon as I found this out I took steps to get an agreed record of what had been decided, and got some board members to participate in telling the developer. Then I announced it to the developer meeting, who decided to formally object to the board.
When the first report came to the board, I answered that there are some details that I wanted to discuss on a technical level, but it was broadly accurate. The head of the project, Len, criticised me for not reporting the weaknesses earlier.
The truth is a bit different. Eighteen months ago I wrote a report on this. One reply from a board member described my report as grossly offensive to Bert, and said I should be sacked.
At that time I agreed to a plan which has since been carried out, to retire some second hand code in this area, and thereby solve one set of problems. This left the other problems in place, that we will now address.
Bert probably thought that this plan solved all the important issues. I always thought there would be a second round. I was able to agree to the first plan partly because it reduced Bert's power of veto in the project.
Now Bert has a test, one which most of us face a few times in a career: whether to accept correction and grow with it, or whether to decline to learn. He could become a developer of great stature if he takes the first road, which is why I consider the LM's conduct so appalling.
I'm glad that these issues are being addressed, but for choice I would have delayed twelve months. Some more evidence would probably have come in that would have made the issues clearer and the discussion less tense. The weaknesses don't have much customer impact at present.
When is the right time to take a decision? Before the product is needed by the customer of course. But preferably not so early that the discussion will be in terms of opinion and individual experience: preferably after all evidence that will be available has been collected. And not so early that there will be time to reconsider before putting it into practice.
Developers vary a lot in their tolerance for uncertainty. Some don't like deferred decisions, and will be keen to discuss them now. When you have the responsibility to lead (in your job description or de facto) you have to be careful before expressing opinions, because they may have more weight than you intend.
But on the other hand, Bert could feel that I have haboured a secret plan for two years. That is another way of feeling about the same set of facts. I don't feel sure what is the right conduct here.
What about Bert's "face"?
We think, and Weinberg encourages us to think, that we are grown up when we accept correction.
This only works when critics can self-criticise, but shortly after Weinberg injected what he intended to be a healthy meme, many wounded people, coming from harsh backgrounds, said in effect, yeah, right.
They knew the code of the streets, which is brought into the nice office.
You never admit weakness.
Now, more than thirty years on, we find that the people in control are the people who never admitted fault or wrong, with Bush being exhibit A.
In the West, a culture of amour-propre, a male culture to be sure, was destroyed in the 1960s by a culture of "authenticity".
In Asia I find instead a culture where a man or woman is accorded a quantum of self-respect such that this quantum is MORE important even than minor truth, such as her code sucks.
This seems wrong. But if we take thought, and ponder the utter triviality of any one line of code in applications outside the mission-critical, we have to acknowledge that the employee's dignity and self-respect is more important not only to him but also to the company longterm than a goddamn line of code.
Weinberg's Tao only works in a community of MUTUAL respect, not the one-way kow-tow community of the modern American or UK corporation, whose Mandarins are making a bad mistake, because unlike the ancient Chinese, they do not accord the peasants any equity of any form...any ownership of anything outside the next problem, which the employee never caused in the typical software environment of "teamwork", but has to solve.
Or else.