Sorry for the short post, but I was checking out the blogs which link back here, and I discovered this post over at Raganwald. The short form is that the author tried to write a program that would help people at least be aware of when projects are in danger or failing. He succeeded in writing the program, but failed to sell it, and his thoughts on why, and the current state of project management, are, I think, some of the most on-target and best writing on the subject I’ve seen.
It’s the sign of a great post that a footnote or tossed off comment is, in an of itself, worthy of discussion- and I’d like to do that with this post. In the middle of the rant, he parenthetically drops in:
(This is another reason there is pressure downwards on developer competence in many organizations. Consider two managers: the first staffs up quickly by selecting available developers, who may not be particularly good. In fact, they are less good then the existing team average. The second moves more cautiously, only adding to the team when the addition improves the average competency of the team. Do you think the second manager will keep their job long enough to finish a project? No, because the ticking time bomb of hiring certain types of developers is off balance sheet, but being understaffed is out there for everyone to criticize.)
Now, consider how this affects the technology. If you need to hire thirty programmers in the next six months, you’re not going to be hiring Ocaml programmers. Not even if you broaden the definition of Ocaml programmer to include Haskell, SML, etc. programmers. I question wether you’d be able to hire thirty Lisp programmers in the next six months. Thirty Ruby programmers? Maybe. Thirty Java programmers? No problem.
Plus, if you think about it bureaucratically, you get punished for using an effective technology. Think about it- even in the same language, the best programmers are easily 10x more productive than the worst programmers are. But that just means you get fewer people under you, and every bureaucrat knows that it’s head count that determines how important you are. So the manager with three super-productive Ocaml programmers under him is less important that the manager with thirty trained monkeys. Not to mention the fact that programmer pay is not commensurate with programmer productivity- so you’re not paying those super-productive Ocaml programmers 10x what you’re paying the trained monkeys- you’re paying them maybe twice as much. So not only does the Ocaml manager have 1/10th the headcount, he has 1/5th the budget.
So is there no hope- are we doomed to use Cobol and Java forever? No. My point here is that you can not push a technology by marketing it to the late adopters. Nor should the late adopters be used as a benchmark for a successful technology. Instead, we should concentrate on the early adopters. The Bureaucrats seek success in a cargo-cult style, by imitating the style of successful projects. If you want your project to be successful, use it successfully! If enough people do, then the cargo-cult managers will begin to emulate them. Be careful what you wish for, however- they will only ever duplicate the exterior of successful projects, they will never understand the real reasons why they were successful.
No related posts.
