People will throw a fit about whether or not the meeting minutes were filed in the right place, in the right format, or whether or not someone is in the precise sanctioned work attire... but huge problems will just slide.
The modern corporation is a horrifyingly inefficient waste of time in so many places.
On the other hand big problems are hard to solve. People frequently bemoan the glut of poorly skilled individuals who claim to have software engineering skills. One would assume that that there could be a similar ratio of crap people in other fields, management, for example.
In short; managers focus on these things to an extreme because they are bad at their job and policing people's wardrobe is the fizz buzz of the management world.
[1] http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
Edit: fixed link - thanks
I love finding out there is a single word for something it would take an entire paragraph to describe.
I mean these laws should be taught at school.
Absolutely.
I know it sounds weird and I am probably doing a bad job explaining, but it just seems like some people cannot stretch beyond the pattern that the rules say should be there. You are absolutely right, it doesn't excuse anything, but it just seems like you can make some amazing predictions of post-crisis behavior based on what you think they think the "pattern" should be.
That's the core of "Parable of the Monkeys." I'm not sure what the canonical source is, but here's a concise rendition: http://allhazardscontemplations.blogspot.com/2009/06/monkey-...
A pattern-matcher (and I think you are right about that) would focus on the most out of the ordinary thing, would he not?
I mean a Tiger in coming towards you. Do you notice (or care about) the bustling leaves on the bush?
I think you missed the clause "in abscense of a known crisis will value the pattern over basic feelings". Not being a zoo keeper, I would think a Tiger constitutes a crisis.
I cannot help but think the manager found that there was no current crisis, someone had taken action, he must now take action, then we get the thing out of place. I would assume (yeah, that word) the normal behavior would be to send the tech home with a "great job" and a "we got it from here". Nope, let's fix the pattern.
Sometimes petty issues come from an even darker place, like punishing non-conformity.
In my case I observed a few things which I could not believe from my own eyes. When you put in a lot of effort to deliver to things you are considered not a good team player, some how even the guy who performs the least is considered better than you. You are expected to share both credit and hard work rewards with some one who had absolutely nothing to with your work. Refuse to do so and you suddenly become a bad team player.
You are always expected to be in full dress code, sometimes this takes so much precedence that its often taking as bargaining thing in performance appraisal discussions. You have to be good to your boss, revere him as hacker extraordinar even if he is actually a Jack ass.
The list goes endless. If large corporations spend even 10% of the effort they spend on these things on work, they could move mountains.
This enables them to worry about things like dress code with impunity, as they're relatively free to hire and fire without having to worry about who is going to manage that system that only they knew about.
Then they wonder why they aren't able to deliver exceptional or world-class service.
Literally: Not at all.
The point wasn't that Java = easy, so let's use Java, rather, that the entire mindset of the Enterprise is that THEY don't understand the craft at all. They believe they can swap out developers as easily as they can swap out help desk workers (which also seems easy in theory, but isn't in practice -- a great help desk tech is worth their weight in gold.)
As their intent is to reduce IT workers to a commodity, I would also venture that it's harder to hire the truly talented (more often than not.) The focus isn't on technical excellence, it's on baseline competence, ability to follow SDLC workflows and, basically, to develop consistent amounts of code so that scheduling is as repeatable a process as possible.
There are exceptions to everything, of course, but I'm speaking from my experience working in and consulting for Fortune 50 companies and Federal Government, where the behavior I described is possibly more prevalent than somewhere like Cisco or EMC (read: technology companies), but I stand behind the position as more the rule and less the exception.
Gold. Pure gold.
I've long wandered in the wilderness. I've had years of writing bullshit business applications. I've even dabbled in investment banking (where programmers, excluding quants, are the second lowest paid professionals at the bank, only higher than support/IT people). I've worked on bullshit semi-startups.
Now I work for Google where ironically... I write internal applications. This may seem like a cruel joke but it's really not. There is so much respect for engineering as a craft here that it occurred to me that it's not the writing bullshit business applications that was sapping my will to live, it was the business-types who so consistently treated engineering as an interchangeable cost center.
I've done the freelancing thing too. Never again. The world is full of delusional people who think they're the next Steve Jobs and that their idea, by itself, is worth something (it's worth precisely nothing).