Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

salva (841)

salva
  (email not shown publicly)

Journal of salva (841)

Thursday May 29, 2008
12:34 PM

billion dollar usa corporations and policies

[ #36543 ]
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!!!


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

billion dollar usa corporations and policies 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    • 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... :)

      • 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

  • 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.

    • 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. :)

      • 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.

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

      • 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.

  • 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.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.