billion dollar usa corporations and policies

salva on 2008-05-29T17:34:25

Last week I got a bug report for one of my modules and after investing a long time solving the problem I sent a new version of the module to the reporter for testing with a x.xx_xx version number.

I got the following reply:

I was only permitted to install latest stable version. Company won't allow for unstable or development versions.

That upset my a little because he was developing a new script, the full thing was unstable, so I told him the thing was ridiculous.

Today I have got a funny reply:

...It is against our policy [and any large corporation for that matter] to install Developer Releases, unstable, beta, or test productions into a production environment. That is what I meant. I am sure you can understand the reason why a billion dollar corporation can't run software on a production system that are not official releases [it is just dumb policy but protects the company as well as myself]. Its not ridiculous, its understandable being a large usa company.

I was however able to install the development version in our test system once they created an account for me to install perl modules...

So, apparently, they can not install unstable modules because they perform the development on the production boxes and only use the testing environment as a last resort!

Amazing, something is utterly wrong with this billion dollar usa corporation and its policies!!!


No, that actually makes some sense.

wirebird on 2008-05-29T18:11:41

Say you install an unstable/dev library, and you develop your app with it. You finish testing your app, you're ready to roll it into production, but the *library* hasn't come out of unstable/dev yet. That's what the policy's about.

Re:No, that actually makes some sense.

cosimo on 2008-05-30T20:50:10

Come on, makes sense? Be serious!

This billion dollar guys are relying on free software (read CPAN) to do their job and they won't even take the hassle of testing a new version of this module which has been fixed for them and for free???

Of course, you should release the changes on CPAN, so that they perceive this as "stable". The world is awesomely funny... :)

Re:No, that actually makes some sense.

wirebird on 2008-05-30T21:38:40

I did say *some* sense, not "perfect sense."

It's one of the minor peeves I have with CPAN, though: it's not terribly clear to newbies exactly how mere mortals might go about testing a module, or submitting a new release. Those big red "UNAUTHORIZED RELEASE"s are not exactly confidence-inspiring when one is showing one's boss. Especially when one is part of a "billion-dollar company," which is generally synonymous with "hidebound bureaucracy," especially if there's government contracts involved.

Not saying it's right. Just saying it makes a sort of sense.

Policy

chromatic on 2008-05-29T20:38:19

It's important not to take on any perceived risk, even if you might get your job done sooner, better, or cheaper. "Policy" is the first resort of the incompetent.

Re:Policy

brian_d_foy on 2008-05-30T09:28:41

Policy is also the resort of people who like to keep their jobs. I know a lot of good people hampered by policy. It's not their fault and it doesn't mean that they are incompetent. Sometimes the good people are merely surrounded by incompetents. :)

Re:Policy

chromatic on 2008-05-30T18:04:11

It's not their fault and it doesn't mean that they are incompetent.

I don't mean to suggest either one, merely that businesses which adhere to policy over practicality every time should fail, and fail noisily, as warnings to the rest of the world.

Re:Policy

kjones4 on 2008-05-30T19:34:34

Right. Perceived risk is the key. Never mind the actual risk.

Re:Policy

chromatic on 2008-05-31T02:07:24

You have to measure actual risk, and that takes valuable time away from avoiding perceived risk.

See also the "Upfront design me harder!" school of software development.

You misread

btilly on 2008-05-30T00:25:28

No, they really are developing in a development environment. But the submitter didn't have access to install the module on the development system. And they can't plan on ever releasing the project until your module has been released in production. Managers tend to get unhappy with external dependencies like that.