How to Deal with Managerial Myths
The word myth sometimes means fiction. But it has a deeper connotation. It also means a story of religious significance that explains the universe and mankind's relationship to it. Managers tend to forget what they learned as programmers and believe in certain myths. It would be as rude and unsuccessful to try to convince them these myths are false as to try to disillusion a devoutly religious person of their beliefs. For that reason, you should recognize these beliefs as myths:
More documentation is always better. (They want it, but they don't want you to spend any time on it.)
Programmers can be equated. (Programmers vary by an order of magnitude.)
Resources can be added to a late project to speed it. (The cost of communication with the new persons is almost always more taxing than helpful.)
It is possible to estimate software development reliably. (It is not even theoretically possible.)
Programmers' productivity can be measured in terms of some simple metric, like lines of code. (If succinctness is power, lines of code are bad, not good.)
If you have an opportunity, you can try to explain these things, but don't feel bad if you have no success and don't damage your reputation by confronting these myths belligerently. Each of these myths reinforces the manager's idea that they have some actual control over what is going on. The truth is that managers facilitate if they are good, and impede if they are bad.
Last updated