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.
3 Comments
This is one of the key advantages that small business has over large business. In small business (where budgets are real things), productivity per dollar and return on investment are critical metrics: there simply isn’t room for developers who aren’t carrying their own weight. It’s part of the reason I love contracts at smaller companies: you simply aren’t going to bump into a person who makes their living hiding in their cube and cranking out a minimal amount of work possible. With that, you tend to see ingenuity as a necessary hiring criteria: creative problem solving and identify potential business wins are everyone’s problem, not just upper management’s.
Life is very different in large business and government, where budgets are fictional, hand-wavy kind of things. With limited exceptions (and I’ve had a privilege to work at just one of these), project importance (and therefore management importance) is measured in terms of budget, staff size, and length of project. So doing something right the first time, with a short development cycle and minimal maintenance, is a actually discouraged. Mix in under-compensated developers with poor morale, and you’ve got a winning recipe!
Of course, the one person who can blow the whistle on all of this is a customer that never sees any real progress. So the job of management therefore becomes faking progress when there is none.
Now, what I’ve come to realize since that blog post is that this isn’t explicit. It’s more insidious than that: it’s not that managers are Machiavellian creatures scheming to game the system, but rather that the system of punishments and rewards in some businesses are structured to get this behavior out of them. In short, bad business cultures are doing this to themselves. Telling the customer that it’s simply not possible to deliver all the functionality in a too-short time frame is punished severely: complaining about being understaffed to meet expectations is part of the status quo, and therefore acceptable. Trying to integrate support for a new process, technology, language or library into the business, even if it is more domain-appropriate and productive, is an uphill battle against bureaucratic inertia and an assumption of risk: selecting the same limited technologies and failed processes is part of the status quo, and also acceptable.
I can’t count how many project “post-mortems” I’ve sat through where the project managers pinned blame on everyone and everything but themselves. Even when confronting a failed or late project with the benefit of hindsight, the people responsible don’t acknowledge their part in creating the broken process or ignoring the danger signs.
Often by the time the customer finds out that their project is in trouble they have no choice to push ahead with the same team and process; starting over would cost too much or push the delivery out even farther. That’s how poorly-executed projects turn into death marches with a dysfunctional team married to a hostile customer.
The word is “than”. Just doing my part.