Comments on: Raganwald http://enfranchisedmind.com/blog/posts/raganwald/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Rintoul http://enfranchisedmind.com/blog/posts/raganwald/#comment-31097 Rintoul Fri, 15 Jun 2007 16:27:37 +0000 http://enfranchisedmind.com/blog/archive/2007/06/14/256#comment-31097 The word is "than". Just doing my part. The word is “than”. Just doing my part.

]]> By: Greg Jorgensen http://enfranchisedmind.com/blog/posts/raganwald/#comment-31094 Greg Jorgensen Fri, 15 Jun 2007 14:54:31 +0000 http://enfranchisedmind.com/blog/archive/2007/06/14/256#comment-31094 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. 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.

]]> By: Robert http://enfranchisedmind.com/blog/posts/raganwald/#comment-31091 Robert Fri, 15 Jun 2007 13:35:34 +0000 http://enfranchisedmind.com/blog/archive/2007/06/14/256#comment-31091 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 <em>everyone's</em> 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 <em>discouraged</em>. 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 <a href="http://enfranchisedmind.com/blog/archive/2006/05/22/137" rel="nofollow">faking progress when there is none</a>. 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. 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.

]]>