Feature creep. Most developers like to work from a well-conceived plan. You know better. Instead, you allow the client to keep piling on new features right up until ship date. That way we end up with unmanageable code spaghetti full of countless bugs, and we spend more time writing patches and doing revisions. If we've negotiated our contracts right, emergency bug fixes could even mean overtime!
Re-inventing the wheel. When we need to implement basic functionality, most of us will start looking for an open source library or framework to fill the bill. You won't let us cut corners like that, though; you've convinced senior management that open source licenses expose the company to liability. Instead, you have us rewrite that code from scratch and on a per-job basis, so this week's rewrite can't be reused on next week's project.
Choosing the wrong tool for the job. The proliferation of development tools is a wonderful thing -- if you're trying to shave off billable hours. Let programmers choose their own tools and they might complete their tasks in half the time you've budgeted. Someone upstairs is sure to notice. Better to pick a personal hobby-horse and stick with it: You want to use Python to process that data? No way, José; we're a C# shop.
Micromanagement. Whenever the team seems to be running too efficiently, that's the time to take our bearings. What better way than with an all-hands meeting? And maybe we can break off into groups after that. Play your cards right and you can take developers off their code for days at a time. A really great manager can even turn the "short meetings" of agile methods into an endless time-sink. We are on the clock, after all.
Discouraging documentation. Who wants to be replaceable in this day and age? If we actually took time to document our code, someone else could maintain it and we'd be out of a job. On the other hand, in the unlikely event of layoffs, there's only one thing to do with our fallen comrades' cryptic, unreadable code: rewrite it from scratch! But what if senior management knew that most modern languages include self-documentation features? It's unthinkable.
Not enough testing. The best bugs are small bugs -- and they're even better when you have a really big haystack to find them in. That's why you don't budget time to design good unit tests, and you mark all problem areas as bugs to be fixed post-delivery. Plus, if there are QA specialists on staff, you'll stonewall them -- developers have enough people criticizing their work without some outside "experts" raining on our parade.
Yes, I've got to hand it to you, software project managers of the world. Thanks in large part to your diligent efforts, developers are working twice as hard for twice as long, and we're all reaping the rewards: bigger development budgets, more programming jobs, and more billable hours.
Maybe you could next work on keeping developers happy while they're on the job? Judging by this list, though, that's probably too much to ask.