• Rich (unregistered) in reply to Mark
    Should have hit them with a six figure licensing bill on the way out the door for using his intellectual property (ie - the script, and his since the company abandoned it and disavowed it).

    Doesn't matter if they admitted up front or not, what he did would be considered "work for hire" and the company would own all rights.

    just on principal of it
    In this case it's principle. Quick and easy way to remember (from high school): a rule: principle the main object: principal

    captcha: atari - teenage riot!!

  • AdventureTime (unregistered)

    Quoth the originator of today's Watch Those Feathers!: Is the moral of this story "Do the bare minimum and never try to fix problems that aren't yours?"

    I think (well, I LIKE to think) that as a more experienced developer, if I saw a glaring flaw in how a process was handled in an organization AND I had a personal interest in seeing that flaw fixed, I'd try to write up a business case:

    • Define the current process (pointy-heads love flowcharts!)

    • Quantify weaknesses ("The current process takes 6 days. We have experienced a 10% error rate. We required 6 hours of overtime to complete the process.")

    • Define the new process (+10 to dexterity for using a flowchart)

    • Show specifically how the new process addresses weaknesses in the old process ("The new process takes 1 second, never makes mistakes, and requires no user interaction whatsoever.").

    • Show how your proposed change fits into the company's change management model / development process.

    The goal is to win management's heart and soul (ah the sweet soul of management) so that you can get what YOU want -- the f'd up process fixed.

    Normally, doing some amount of scripting that is invisible to management is just part of the most important thing at work: Getting The Job Done. There's an ill-defined line somewhere which, when crossed, marks the start of the tragic slide towards the Mystery Script Environment.

    (Humorous Anecdote, as an aside, told in the tone of voice of Garrison Keillor:

    "After taking my new job as sysadmin at a mid-sized (~4000 employees) organization, things started off a bit ominously when the only note I got from the previous sysadmin read, 'Lots of things are going to surprise you!'. I have not been disappointed.

    The first unpleasant surprise was the email server: it kept crashing, every night, without fail. The logs all looked normal, and tech support couldn't help me identify a problem. The pressure was on and the prospects looked dim. The previous sysadmin, when contacted, smirked and said, "Oh yes, it does that."

    And then a ray of sunshine: a Clue provided by a helpful user. I was getting ready to head home for the day, and had shut off my desktop computer. Moments later a breathless user rushes in to my office, "Email JUST quit working!". My eyes went to my desktop computer -- and back to the user -- and back to my desktop computer. What was it my boss had said about why I couldn't reinstall a fresh OS on my computer? Something about that being a "...bad idea, things are running on it."

    And what do you know? Things WERE running on it. I discovered a cronjob (running as root, naturally -- everyone knows that the only user on a Linux system is the one named "root") named "KickstartEmailServer". Its purpose was to login to the mail server (guess what username?) via ssh and execute a script on the server (touch, anyone?) that updated a timestamp on a file, "/root/EmailKeepalive". Smelling blood, I checked the cronjobs on the server and found one that had an interesting name: "DeadOrAlive.sh". Its purpose? To check the timestamp on the /root/EmailKeepalive file and shut down the email server if the timestamp was more than 5 minutes old.

    I emailed the previous sysadmin about this but never got a response. Maybe his email server was down...?"

    So ends this amusing anecdote.)

  • Productive Coder (unregistered) in reply to danixdefcon5

    I like to keep my automation secrets to myself too. Once I got a Summer job editing screen capture bitmaps so they would look better when printed in the manual. Mainly this involved converting the images to black-and-white and inverting some text boxes from black-on-white to white-on-black and vice-versa. My co-workers did this manually using Microsoft Paint, taking about 15 minutes per screen capture. I used Photoshop to do this automatically in about 2 seconds with a few keystrokes.

  • (cs) in reply to AdventureTime
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up?

    Point is, script cowboys cause problems because their shit:

    • Is developed in isolation, not as part of the development process in use at the organization. So, folks who should be consulted on impact are NOT.

    • Documentation? We're cool script cowboys, we're too busy saving the world to write up any documentation.

    • Testing? Nah. Why test it when it obviously smirk wink smack sink WORKS?

    • Doesn't take maintenance cycles into consideration. "The Script" becomes an item of mystery that is discovered when it breaks.

    • VIOLATES ENCAPSULATION (of departments!) WHICH IS FATE WORSE THAN etc. Scripts can contain hard-coded assumptions which are equivalent to Business Practices . It isn't the technician's (== code cowboy's) job to formalize business practices. Aren't we all (as smug readers of The Daily WhateFer) in agreement that it SuX0Rs when management make technical decisions? So... physician, heal thyself?

    So, no, the WTF is not really the corporation. So what if they don't want to streamline the process by which work is done? It's their dollar.

    Sure, I'll agree with most of that. It is definitely inappropriate for someone to make an unsupervised script to solve the problem.

    Except... no one else was willing to do a damn thing about the problem. That instantly qualifies the situation as a WTF.

    Endless hours of tedious data entry is a near-impossible task for anyone with a modicum of intelligence. To have an obvious solution to drudgery dangled in front of one for hours upon hours, day after day, is a torture that would make Sisyphus cringe.

    The WTF falls squarely on management and those "first tier programmers" for being too incompetent and/or recalcitrant to solve the problem, and for ignoring the terrible working conditions (in IT terms, at least) of the "lowest class" people.

  • Mandor (unregistered) in reply to AdventureTime
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up?

    Point is, script cowboys cause problems [snip]

    Having been on both sides of a "script cowboy" sort of situation, some comments:

    • The company ended up using his script, but removed his name and otherwise didn't give him credit. That makes this whole business seem more like a turf issue or other bad faith rather than a real effort to protect the IT environment.

    • The IT department here had said that this item was impossible. What A. Thompson did clearly demonstrated that it is possible, regardless of code quality issues.

    • I, too, have seen instances where a script was poorly written. Some specific bad techniques are: (1) busy waiting; (2) putting configuration items in the body of the script instead of in an external config file or at least in up-front variables; and (3) no error checking at all. In most cases, though, the correct solution is to "gently" tell the user to rewrite the code according to some standards. Maybe do peer review, too. And maybe get the IT guys to genuinely rewrite the code using their high standards -- giving suitable credit to the guy who came up with the idea.

    So the fact that they yelled at him might make sense. But reusing his code without giving him credit is inexcusable.

  • [twisti] (unregistered) in reply to Rich

    I'm not American, but can't you sue for that kind of stuff ? As far as I know, nobody can take your source code and put a different name on top of it, not even if you work for the same company.

  • lrucker (unregistered)

    In 1996, I worked at a company that created a cross-platform product. Ran on Mac, Windows, Solaris. I was the Mac person, supposed to write the UI but there was no VM yet to run it on (you should be able to guess what this is). Now, the Mac code was built in CodeWarrior, the rest of it in good old make.

    The instructions for building the Mac said "now visually compare your CW project to the make files and update it to match." Er, not hardly, not when the contents of the makefiles change on a daily basis because this is pre-alpha stuff. The Windows people were pretty good about updating the Unix makefiles and vice versa, but even switching to MPW wouldn't help; vi can't cope with those lovely funky continuation chars MPW is so fond of.

    So I spent two days converting all the unix/windows makefiles to keep their file lists in make's version of "include" and writing DOS and MPW scripts to convert path separators from '/' to '' or ':' so the Windows and Unix people didn't have to edit two files per change. And everyone was happy, and years later I overheard a training class being told "do not ever put a filename anywhere but the include file".

    Meanwhile the other new "Mac" programmer spent the same two days visually comparing the makefiles to his CW projects. Funny thing, when he quit only a few months later, nobody could find any code he'd written.

  • khchung (unregistered) in reply to danixdefcon5
    danixdefcon5:
    Aaaaaand ... that's why automated stuff, if it works OK (as in "no weird stuff happening"), must be kept a secret.

    That way, you do everything quick, slack off the rest of your allotted time slot and save yourself from stoopid management reprimands.

    Exactly! If you found a way to automate it, you keep it to yourself, so you appear to be very productive while making very little mistakes.

    From a cynical point of view, you are paid to do the work given to you, you are not paid to automate that job!

    From a practical programmer's point of view, writing a program that YOU can use is much simpler than writing a program that OTHER PEOPLE can use, usual estimates is a difference of 3x. So if you tell people about your automated scripts you are using, you are facing a twice again the effort so other people can effectively use the script.

    Reveals your automation only when you manager (or maybe, only maybe, a coworker you trusts) come and ask "what's your secret". And do so ONLY WHEN YOU HAVE OTHER MORE VALUABLE WORK TO DO! Otherwise you will automate yourself out of your job! You tell them "this is the way I work", you DO NOT sell it as a way to change how other people works (because that way you are usurping your boss's territory).

  • Jeff (unregistered)

    There are some people on this forum that have real big egos.

    "My editor and the code that goes with it is the life blood of the company"

    Get real dude...........

  • mike (unregistered) in reply to [twisti]

    No. In America, the general rule of thumb is:

    anything you work on during company time/using company resources belongs to the company. 100%.

  • mike (unregistered)

    "Ironically, almost ten years from that day, A. started work at a company that uses that same pipe-delimited data generated from Herald Media Services. Hopefully, it’s still automatically generated."

    No. That is NOT ironic. That is coincidental.

  • cardboard box (unregistered)

    I would have quit at the moment I had seen what I was expected to do... A programmer that can stand the mindles numbness of copy-paste!? I do not belive people like that exist.

    Things that can be automated should be automated. Even if the automation requires a person supervising it. Its an organizational WTF how this can happen.

    Those that say that things you do on companys time are company peoperty... WELL as far as I understand copiryght law company owns all rights to do with your work as it pleases EXCEPT! and this is important, thers nothing that allows them to take away your rights to be quoted the author of this script! You have made it, your name should be bound to it...

    Howerver scriptcowboys can be a pain in the but. I came straight out of university to work for a startup company where automation was nonexistent at a position wher no-one knew what it was that they were going to make out of me so my boss then gave me a job of parsing some log data in text files. I saw right away that this called for a database to be sensibly used and implemented as such. Year later what I had started had become a business critical application at its version 2. Then this truly oldschool guy walks in as an engeener takes one look at what I have done, sees PHP("Uhoh, this is the hip language kids use these days...") and a database ("What a scarry complex thing it is!") and starts all over with what I had started some time ago but using visua basic and getting stats throug parsing a milion text files every time some data is needed without even telling me... And then pestering us at IT with complaints that his PC is too slow.

  • Chris Dial (unregistered)

    I think that it is OK to do this kind of thing, but that you need to collaborate with management first to make sure what you do is not going to cause a problem. And there should ALWAYS be documentation.

  • Anonymous Tart (unregistered) in reply to [twisti]
    [twisti]:
    I'm not American, but can't you sue for that kind of stuff ? As far as I know, nobody can take your source code and put a different name on top of it, not even if you work for the same company.

    As you aren't American, I'll assume European? In the UK, if you do it at work, or during work, then its not your source code - its theirs. Nothing you write at work is yours, in any respect.

    Depending upon your contract, there can be more restrictions - for example, any code I write is the property of my employers, regardless of when I write it. In reality though, thats just an HR/legal big stick, its more Q: "I've written libfoobarquuz, can I BSD it?" A: "Yes"

  • (cs)

    This is such a good story, it should be on The Daily WTF!

    OK this joke is probably stale now. I'll stop it.

  • CH (unregistered) in reply to Steve
    Steve:
    My goodness.

    Stories like this one and many of the others I see here make me oh, so, glad that I'm in academia and not in the "real world".

    You mean because you've got all this to look forward to?

    Fittingly, the captcha is craaazy.

  • Too lazy to register!! (unregistered)
    [twisti]: I'm not American, but can't you sue for that kind of stuff ? As far as I know, nobody can take your source code and put a different name on top of it, not even if you work for the same company.

    As you aren't American, I'll assume European? In the UK, if you do it at work, or during work, then its not your source code - its theirs. Nothing you write at work is yours, in any respect.

    WTF... What kind of an assumption was that!!!

    Anyway, the source code you write at work is the comany's property, but that doesn't still accord any individual within the company a legal right to move the credit from another individual to himself/herself....

    To the outside world, the code is apporpoerty of XYZ Inc. but internally within XYZ, the credit for the code would still go to the individual who wrote it.... In this particular case, it's nothing but pure plagiarism by the bosses...

    Oh, and for the record, I am from Asia (India)!

  • GreyWolf (unregistered) in reply to Too lazy to register!!
    Too lazy to register!!:
    [twisti]: I'm not American, but can't you sue for that kind of stuff ? As far as I know, nobody can take your source code and put a different name on top of it, not even if you work for the same company.

    As you aren't American, I'll assume European? In the UK, if you do it at work, or during work, then its not your source code - its theirs. Nothing you write at work is yours, in any respect.

    WTF... What kind of an assumption was that!!!

    Anyway, the source code you write at work is the comany's property, but that doesn't still accord any individual within the company a legal right to move the credit from another individual to himself/herself....

    To the outside world, the code is apporpoerty of XYZ Inc. but internally within XYZ, the credit for the code would still go to the individual who wrote it.... In this particular case, it's nothing but pure plagiarism by the bosses...

    Oh, and for the record, I am from Asia (India)!

    In UK (and probably elsewhere in EU), it depends on whether you are an employee or not. Code written at work by employees is owned by employer. Code written by contractor is owned by contractor UNLESS ownership is assigned in contract to client (it usually is, but occasionally there's a dumb cluck who lets me own my code)

    Captcha pinball .. I am the Wizard

  • Not a lawyer (unregistered) in reply to GreyWolf
    GreyWolf:
    Too lazy to register!!:
    [twisti]: I'm not American, but can't you sue for that kind of stuff ? As far as I know, nobody can take your source code and put a different name on top of it, not even if you work for the same company.

    As you aren't American, I'll assume European? In the UK, if you do it at work, or during work, then its not your source code - its theirs. Nothing you write at work is yours, in any respect.

    WTF... What kind of an assumption was that!!!

    Anyway, the source code you write at work is the comany's property, but that doesn't still accord any individual within the company a legal right to move the credit from another individual to himself/herself....

    To the outside world, the code is apporpoerty of XYZ Inc. but internally within XYZ, the credit for the code would still go to the individual who wrote it.... In this particular case, it's nothing but pure plagiarism by the bosses...

    Oh, and for the record, I am from Asia (India)!

    In UK (and probably elsewhere in EU), it depends on whether you are an employee or not. Code written at work by employees is owned by employer. Code written by contractor is owned by contractor UNLESS ownership is assigned in contract to client (it usually is, but occasionally there's a dumb cluck who lets me own my code)

    Captcha pinball .. I am the Wizard

    Yes. They own the code, but I think they still can't change the name of who wrote it. Your boss can't take your code and say that he wrote it himself (I think)

  • Plasmab (unregistered)

    Changing the name of the author is breach of copyright. He could simply sue them.

    I would

  • Anon (unregistered)

    erm, "programming" means something different in TV land doesnt it?

    So it was never a "computer programming" job, it was a "making a program of whats on tv" job. Like you can get a "program" at an opera, or the saying "get with the program".

    I bet A. got the job via a recruitment agency who didnt know their "programming" from their "programming".

  • Plasmab (unregistered) in reply to Anonymous Tart

    Actually your are completely wrong. In the UK (where i work) you own the copyright to every bit of code you write. BUT you do not have the right to use, sell or otherwise distribute that code unless you have either written permission from your employer or have no non-disclosure agreement with your employer.

    I know this because i've used the latter of these clauses on a previous employer who didn't pay me.

  • Mark B (unregistered)

    Who hasnt heard of this : "Junior" Programmer writes something he shouldnt which makes life so much easier. "Junior" Programmer gets told off for wasting his and the companies time. Senior Programer looks at code realises its quite good and uses it anyway but changes the name on it to his rather than the maker.

    This has happend to me at least twice in my carrer. Now I'm a senior developer level and knows how it feels. I wouldnt do it to another developer at any level. I'm not that insecure.

  • (cs)

    I worked for a Fortune 500 company solution company. Most people who worked with them or know their reputation would probably say they are stodgy, slow, and every fart has to be documented. My manager actually encouraged cowboy scripting. He'd stop and leave me a piece of paper with a little report or script drawn out. Then I'd get a covert phone call where he'd be whispering about what he needed.

    Our group actually did really well and we took over some office space. That way we could meet and conspire in private around some people who didn't know what we were talking about.

  • cardboard box (unregistered)

    What people seem to confuse around here are two terms as to rights to your work.

    There is Copyright, witch is owned by your employer, what gives the company right to do almost what it likes with the code.

    And thers Authors Rights. Basicaly thats something that noone has the right to take away from you. It cant be traded or sold. It is your right to be acknowleged as the author of something.

  • Jon (unregistered) in reply to evilghost

    Did he ever consider that he was writing to the code/script that was going to make his entire department unnecessary? Why keep all those data-entry folks on the payroll when the script does it.

    OMG Oh No... why don't we stop technical advancement all together!!

    It's my job to eliminate jobs like this. If possible id eliminate my own job. I free up company personal resources so human resources can be let go or utilized elsewhere. This makes the company more profitable which makes it a more stable job for me and my co-workers. A little house keeping on the staff prevents massive layoffs in the future. It's darwin...

  • DM (unregistered)

    Forget ROI, NPV, etc. - the most important ratio in work is:

    (the time it takes for you to do the work) divided by (the time they think it takes for you to do the work).

    The happy zone is anywhere below 0.8

    I think this is called the Dilbert ratio, or something.

    ;-)

  • (cs) in reply to AdventureTime
    AdventureTime:
    So, no, the WTF is not really the corporation. So what if they don't want to streamline the process by which work is done? It's their dollar.

    You're absolutely right. Why should the corporation want to automate an error-prone, tedious manual process instead of automating it and eliminating the errors?

  • Nazi (unregistered) in reply to Chris Dial
    Chris Dial:
    I think that it is OK to do this kind of thing, but that you need to collaborate with management first to make sure what you do is not going to cause a problem. And there should ALWAYS be documentation.

    BUT...

    The documentation will go missing, your comments in the code will be removed for efficiency's sake, and we'll all complain that some "cowboy" didn't follow any procedures or protocol within an F'ed up company.

    And so we are all part of the everlasting circle of life.

  • (cs) in reply to Mark B
    Mark B:
    Who hasnt heard of this : "Junior" Programmer writes something he shouldnt which makes life so much easier. "Junior" Programmer gets told off for wasting his and the companies time. Senior Programer looks at code realises its quite good and uses it anyway but changes the name on it to his rather than the maker.

    This has happend to me at least twice in my carrer. Now I'm a senior developer level and knows how it feels. I wouldnt do it to another developer at any level. I'm not that insecure.

    I must be evil, but I can't help seeing a "yet" at the end of the last sentence :-D

  • (cs) in reply to KenW
    KenW:
    AdventureTime:
    So, no, the WTF is not really the corporation. So what if they don't want to streamline the process by which work is done? It's their dollar.

    You're absolutely right. Why should the corporation want to automate an error-prone, tedious manual process instead of automating it and eliminating the errors?

    It's not like it's the reason why computers were created in the first place.

  • A. Thompson (unregistered)

    ewtn|2||y||||0|n||||3|auto|y|n|n|n|| espn|3||y||||3|y||||3||y|n|n|n|| fxw|5||y||||0|n||||3||y|n|n|n||

    Sorry, flashback >.>

    As far as writing a PRD/Plan/TechSpec/TPS Report, such things would have only confused them. This wasn't 'big city' programming, we were in the middle of farm land. And 10m away from a fantastic amusement park!

    The level of incompetence at this place can be measured from the fact that they had a half-million dollar database server storing some of the data. But one of the other data tables were stored on a $500 web server.

    The conversation went something like: Me: "Hey, I think if we did..." IT: "No, we've looked in to it, we can't merge the data." Me: "But we can just download this..." IT: "No, we don't have the resources to make it happen. Besides it wouldn't work out right in the end." Me: "But look, I started doing this and that and I managed to..." IT: "Oh look, lunch is here."

    Or:

    Me: "So I think I can really save some of these 3am calls." Managers: "Oh! Tell me more!" Me: "Well I think I can automate the text-file process." Managers: "Didn't IT say it was impossible?" Me: "Well yes but, I don't think they've considered..." Managers: "Oh, well they don't have the resources, and besides it would work out right in the end." Me: "But if you just..." Managers: "Oh look, shiny."

    This was a long time ago though, my memory could be fuzzy ;)

  • Worf (unregistered) in reply to Anita Tinkle
    Anita Tinkle:
    Is "Herald Media Services" a Pennsylvania-based concern? If they are, I know exactly who these people are. :-)

    I dunno where Tribune Media Services is located (you may know them from tvlistings.zap2it.com), but that's where I'm guessing the story took place. There aren't many other TV listing providers out there (TV Guide...) for North America.

    At least, I think that's the relation. After all, there's the Herald-Tribune, so...

    CAPTCHA: dubya - I assume even he can figure out the company name!

  • Pecos Bill (unregistered) in reply to snoofle
    snoofle:
    Since they had seen how everything was fixed, and no sign of sabotage, they sort of had to eat crow. From then on, they never messed with me again.

    Priceless. David triumphs. Alas, the stupidity probably raged on.

  • (cs)

    So freaking unfair! I've been there in the past and don't think it's funny ¬¬

    Cheers

  • Obi Wan (unregistered) in reply to SomeCoder

    I was going to respond similar to "SomeCoder", but he obviously beat me to the punch.

    The WTF is with the company. The person did apparently "test" it (and did get results, WHICH IS WHAT HE IS BEING PAID TO GET, may I remind you). Procedures are there to be followed, in theory, yes - but in an environment like that, you can get stuck with stupid procedures.

    Management's job is to MANAGE - i.e., find ways to make things run faster, better, cheaper. One easy way to do this is be open to your competent employee's feedback since they, being in the trenches, have a different viewpoint than you and may have a suggestion worth looking at. The manager makes the final determination. This is the only error committed by the employee - not communicating this to management - except he knew already management didn't want to hear it (first rate programmers decreed it can't be done, that's the end of that!) So what else was he supposed to do?

    To me it's clear management FAILED to do their job, as something clearly demonstrated that was faster, better, cheaper, was REJECTED. Which is the point of this WTF.

  • SS (unregistered) in reply to mike
    No. That is NOT ironic. That is coincidental.

    It's definitely not ironic, and it's only sarcastically coincidental. It should read, "As expected".

    SS

  • Kyevan (unregistered) in reply to Rich

    FAIL! What if one of them had listed as something OTHER than M or F?

    CAPTCHA is gotcha. Is this thing psychic?

  • Ack (unregistered)

    The thing that really bugs me is that someone else then took credit for his ingenuity.

    An online betting company hired myself and two other developers to bring their sprawling IT department total to 5. One of the developers was useless and he worked out pretty quickly that he'd sold himself into a position that he wasn't capable of holding down. His solution? Take credit for everyone elses work. He'd spend his day trying to work out his little javascript issue and constantly ask myself and the other new guy how we were going. If we said we'd finished any of the components we were working on he'd promptly send out an email to everyone from our direct manager to the managing director of the company proclaiming 'such and such a piece of work was now complete'. He never actually said he'd finished it but he conveniently left our names off of the CC'd list. When they made him the team lead of a dev team of 2 myself and the other developer both resigned to make him a team lead of 0. From what I've heard from the sys admin guys I'm friends with they now turn over developers every 6 months or so, he is still leading the dev team and apparently they are planning on making him the IT manager (in charge of dev and the sys admin guys) when the current one retires later this year.

  • Anon (unregistered)
    A. checked the script and noticed that it was almost identical to the “improper” script he had created; the only difference was that his name on the comment header was replaced with someone else’s in the Professional IT Department.

    That's called plagiarism, and it's illegal. Yes its even illegal within an organisation where you don't own the IP of your own work.

  • (cs) in reply to Plasmab
    Plasmab:
    Changing the name of the author is breach of copyright. He could simply sue them.

    I would

    It's not a breach of copyright, because if you get paid to write something, then the people paying you own the copyright. So in this case, all the code is owned by the company, whoever takes credit for writing it is irrelevant to IP ownership in this case. However, taking credit for someone elses work, irrespective of who the copyright owner is is plagiarism, which you can get them in trouble for.

  • ChrisW75 (unregistered)

    I'd have been absolutely furious in that position. Most of the work I do revolves around making peoples jobs easier by finding ways to do things better through automated or standardised processes. I'm a programmer, that's what programmers DO. My question in that situation would have been "If IT said it couldn't be done, and I managed to do it in my spare time without their help, why aren't IT in here being dragged over hot coals for not being able to do their job properly?" Man, I'm getting angry just reading this.

  • Andrew (unregistered) in reply to snoofle

    I completely agree, but the problem here is running it on your local machine. I've worked for companies where almost the entire infrastructure support department was automated from crons from individual users accounts on their own machines, on file servers, on phone servers, etc. Most of the scripts I've seen don't comply to any standard error reporting - some log to some random file, some write all output to STDERR, some email the user, some don't log at all! Some depend on some random perl module - some are in bash, some are in tcsh, some require some random environment variables, etc.

    I'd rather have someone manually do a task than run it under their local account from their workstation.

    Its frustrating to have to go through official channels, especially when they don't approve of the script, but thats the cost of doing business.

  • (cs) in reply to Jeff
    Jeff:
    There are some people on this forum that have real big egos.

    "My editor and the code that goes with it is the life blood of the company"

    Get real dude...........

    Actually, you do not know how true this type of case is with many companies. Take away the touch of automation implemented by some administrator/developer and witness the chaos, or the reverting back to primitive labour, that ensues.

    Just about every (modern) company functions on software, be it hand-made or bought, lousy or superb.

  • Some Farker (unregistered)

    I was working in the IT dept at an insurance-ish place a few years ago. One of my daily tasks included processing and generating reports for our call centres, a task which not only required me to show up before 6:30 to start, but also monopolized my entire morning.

    By the third day, I was entirely sick of it... So I installed PHP locally and whipped up a script. Due to the call center's data being an MS Access database, I was tied to Windows, but I was at least able to use Access's DOM magic to run the required data manipulation/querying. After adding in error catching/reporting/etc and the FTPing of the file from the call centre/to our backup server, printing reports to the printers of the various bean counters, etc etc, my script was complete.

    Long story short? This task went from requiring me to show up at least an hour earlier than everyone else AND spending 5ish hours of my day to being complete before I even showed up in the morning.

    With the monotony out of the way, they gave me actual programming work. And it was actually interesting, to boot.

  • (cs)

    I'm sure there is a proper procedure that he might have followed, or at least a more admirable procedure.

    Having written his script in his spare time, he could have sent a memo to the Professional IT department etc outlining the work they do and how it might be improved, with details of his script.

    He may also have approached his line manager and requested a move to the Professional IT department, which he was eventually offered anyway.

    Any scripts he writes with regard to company business would in any case belong to his company, not to him personally.

    If they still came back with the "impractical" stuff then perhaps would be the time to seek an alternative.

    Many of the issues seem to be HR related - they divide the staff into departments and have set ideas as to what each department may or may not do. Too often HR interfere where they really should not.

    I have also found interviews can be misleading - they paint a rosy picture about what they do and then you find that someone else is doing it and not you and you are the 2nd class or 3rd class programmer.

  • Earl Colby Pottinger (unregistered) in reply to AdventureTime
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up?

    Point is, script cowboys cause problems because their shit:

    • Is developed in isolation, not as part of the development process in use at the organization. So, folks who should be consulted on impact are NOT.

    • Documentation? We're cool script cowboys, we're too busy saving the world to write up any documentation.

    • Testing? Nah. Why test it when it obviously smirk wink smack sink WORKS?

    • Doesn't take maintenance cycles into consideration. "The Script" becomes an item of mystery that is discovered when it breaks.

    • VIOLATES ENCAPSULATION (of departments!) WHICH IS FATE WORSE THAN etc. Scripts can contain hard-coded assumptions which are equivalent to Business Practices . It isn't the technician's (== code cowboy's) job to formalize business practices. Aren't we all (as smug readers of The Daily WhateFer) in agreement that it SuX0Rs when management make technical decisions? So... physician, heal thyself?

    So, no, the WTF is not really the corporation. So what if they don't want to streamline the process by which work is done? It's their dollar.

    Sorry, I must disagree.

    All your above points boil down to the requirement that such an important script should only be developed by the first tier of the IT department.

    However, that department has already declared the code impossible to write, and when an example of a working script was shown them just changed the copyright - no correction, additions and certainly not a rewritten version from the ground up. The IT department is a big WTF because the third tier is better at the job than the first!

  • A. Thompson (unregistered)

    I never tried to elude to the point that I didn't make a mistake. I was just being me. I am a problem solver. I've since worked for companies that want their problems solved, though older and wiser with nothing to prove anymore, I follow procedure. If someone doesn't want something fixed, I won't fix it.

    I've learned to be more selective about the places I work for now, trying to find groups of people to work with that share my same ideals. So far that's worked out real good.

    I haven't been sat down in a room full of angry IT people to be chastised since, so that's a start!

  • C (unregistered) in reply to Volmarias
    Volmarias:
    ... Turns out that, like quantum physics, he had changed the state of these logs simply by observing them. So, the last access times were changed from 2 weeks in the past to the date at which he ran the script. That would be ok, except it also turns out that real, developed by IT scripts were also viewing those logs, and were parsing the access time. Which was now "5 minutes ago" for every single log.

    Shortly thereafter, a nastygram circulated the staff, chiding whoever had caused this problem and suggesting that they may not want to do it again. My friend quickly removed his script from the server and dropped the idea completely.

    Moral of the story: sometimes there's a reason to not write that script.

    Sup, V.

    Ah, but this could easily have been fixed by getting the time before the access and restoring it using 'touch' or another command.

    Double-sadly, about a week later, it turned out that someone was grepping every single log file at the same time for certain unremarkable strings. This kept the server load very high as well as changing the dates on every file to the current time. Those hosts no longer allow shell access. :-)

  • cognac (unregistered) in reply to Kyevan

    Then it would be at the top, bottom or right at the M/F boundary in the sorted file and so it would be easily noticed.

    It would also be invalid data.

Leave a comment on “Impossible, Impractical, and Too Expensive”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article