Cultural regression
I work on a development team that for the last year or so was making a lot of progress toward being effective at #1 delivering useful software, but #2 responding to stimulus with the appropriate level of response.
At this point, however, we've fully regressed to our previous state of overreacting to very small stimuli. A small configuration change to a server and we act as if we've discovered the Russians (no offense to anyone from there) have launched their entire nuclear arsenal at our office building. Any small hiccup results in finger pointing, conference calls, and multiple teams running off to the excuse factory to build something to explain why something went wrong.
Heaven help the poor sap who tries to actually fix or avoid the problem, he will be beaten down with a litany of things that SOUND really bad and scary, but in fact have little or no real impact. I believe this is happening because folks are fearful of their jobs and want to give the impression that they are hard workers who are dedicated to getting things done. It seems that in this case, there is little interest in solving the real problem, because reacting the the problem of the day comes with reward for "lot's of hard work" and of course appreciation for the "countless nights and weekends by dedicated associates".
The cynical side of me thinks that many people are over-blowing the real problems in order to make sure everyone understands how IMPORTANT they are. One perennial problem that impacts me personally is an age old ( in our organisation) debate about source code control. For one, I am stunned by, and somewhat ashamed of, the sheer number of hours we have wasted on this debate.
At one point we gave up and just used Clearcase, but the sheer effort required to keep this tool afloat caused us to go underground and begin using SVN again. We then ended up formalising SVN within the organisation, but this ironically has caused MORE problems. More problems stem from the fact that the change management team, because they don't understand or WANT to understand the developers, just tells people to "do whatever they want" with SVN instead of having them follow good practices. This has the predictable effect of causing inexperienced developers to fall into obvious and predictable traps that could easily have been avoided had the change management team spent some time helping craft good practices using the tool.
Right now, we're busy attributing problems in the development process to SVN, RAD, Eclipse, Groovy, and a million other tools. The problem is, as far as I can see, all of the problems are really being caused by PEOPLE not tools. The tools are just convenient excuses and witless pawns in the game of "it's not MY fault".
At this point, however, we've fully regressed to our previous state of overreacting to very small stimuli. A small configuration change to a server and we act as if we've discovered the Russians (no offense to anyone from there) have launched their entire nuclear arsenal at our office building. Any small hiccup results in finger pointing, conference calls, and multiple teams running off to the excuse factory to build something to explain why something went wrong.
Heaven help the poor sap who tries to actually fix or avoid the problem, he will be beaten down with a litany of things that SOUND really bad and scary, but in fact have little or no real impact. I believe this is happening because folks are fearful of their jobs and want to give the impression that they are hard workers who are dedicated to getting things done. It seems that in this case, there is little interest in solving the real problem, because reacting the the problem of the day comes with reward for "lot's of hard work" and of course appreciation for the "countless nights and weekends by dedicated associates".
The cynical side of me thinks that many people are over-blowing the real problems in order to make sure everyone understands how IMPORTANT they are. One perennial problem that impacts me personally is an age old ( in our organisation) debate about source code control. For one, I am stunned by, and somewhat ashamed of, the sheer number of hours we have wasted on this debate.
At one point we gave up and just used Clearcase, but the sheer effort required to keep this tool afloat caused us to go underground and begin using SVN again. We then ended up formalising SVN within the organisation, but this ironically has caused MORE problems. More problems stem from the fact that the change management team, because they don't understand or WANT to understand the developers, just tells people to "do whatever they want" with SVN instead of having them follow good practices. This has the predictable effect of causing inexperienced developers to fall into obvious and predictable traps that could easily have been avoided had the change management team spent some time helping craft good practices using the tool.
Right now, we're busy attributing problems in the development process to SVN, RAD, Eclipse, Groovy, and a million other tools. The problem is, as far as I can see, all of the problems are really being caused by PEOPLE not tools. The tools are just convenient excuses and witless pawns in the game of "it's not MY fault".
Comments
Going with the flow isn't your style. Forget about those architecture goons, roll your own tools and just keep making magic.