• Didakos (unregistered)

    A happy ending? :O

  • Black Bart (unregistered)

    Not the usual run of the mill WTF: I expected Aikh to be fired, but instead he was promoted for doing the right thing.

  • Miriam (unregistered)

    Nice story, keep the good work up!

  • Peter (unregistered)

    This story is lacking important background information: Was Aikh a Ninja?

    /s

  • TroelsL (unregistered)

    Excellent story, not overly embellished and holds a real WTF and a realistic scenario.

    Thank you for listening, TDWTF!

  • foxyshadis (unregistered)

    Normally it takes longer than that, but if you're a cool dude and help regular people with a smile, some businesses and departments will bend over backward to get whatever you say you need to make their lives easier.

    Nothing you can do about the rest but move on as soon as you can, but you probably didn't want to work there anyway.

  • Tripmine (unregistered)

    Wait,what...is this ragnarok? A positive story with no confusing embellishments?

  • Excelsior (unregistered)

    TRWTF is Aikh not resigning like they all usually do

  • (cs)

    Erik, this is how to write a WTF. Ellis didn't have to spend 10 paragraphs rambling about Aikh being a wannabe ninja/warrior/Jedi, and she didn't have to flaunt what she learned in freshman literature class and tie him to a well-known literary work based on nothing but the country the "WTF" took place.

    Well done, Ellis.

  • Anonalzar (unregistered)

    Unfortunately such attitude is not uncommon in the IT field.

    A company I previously worked at had no issue seeing horrible bugs in the application, given the fact that support would become valuable. We could just have enforced a few common best-practices and most of the issues would have disappeared "magically". Had "each developer has to test his own code or will be in trouble" been applied, we would have gained hundreds of hours of deployment ping-pong.

    However when I proposed such practices, I got an arbitrary "NO" response back. I no longer work there. After checking out of curiosity, I see that they are still producing questionable work. Good riddance. They have an excellent sales team however.

  • Dave (unregistered)

    Wait, nothing in his contract about leaving to go and work for the client?

  • (cs) in reply to Dave
    Dave:
    Wait, nothing in his contract about leaving to go and work for the client?
    Since the "client" was another business unit of the same bank, I doubt it.
  • ANON (unregistered) in reply to Dave
    Dave:
    Wait, nothing in his contract about leaving to go and work for the client?

    The client was just another business unit. Why should it be forbidden?

  • Wolfraider (unregistered) in reply to Dogsworth

    Agree, make comment blue

  • Smug Unix User (unregistered)

    You can have wool for years, but lamb chops only once.

  • (cs)

    so, why not just use google to find what you need instead of relying on that guy?

  • QJo (unregistered)

    Had similar encounters with questionable under-automation practices.

    In a position where I was responsible for maintenance of a whole articful of internal service tools, I would often see opportunities to streamline the process. One memorable time I had been tasked to upgrade one of the command scripts to update the year. Yes that's right, the year was one of the fields which was hardwired into the script so the user did not have to enter it. Every year it had to be amended so as to reflect the current year's activity. All well and good -- to relieve the user the responsibility of entering the current year would on the surface seem like a good idea. Except that what the user did have to enter was a series of filenames, all very similar but not quite the same (and in which the month and year featured). It was a quick and easy task to upgrade the script so as to allow the user to enter only the month and year, and it would automatically populate the filename variables to feed them into the programs that needed them.

    It was of course rejected by the Services team -- they were used to the way it worked, and weren't prepared to take on the extra training task of learning what to enter when presented with the command: "Please enter the month and year".

    Besides, sitting in front of a terminal typing away manically made the service staff look far busier than merely sitting waiting for the computer to finish it's not-very-long run.

  • Tux "Tuxedo" Penguin (unregistered) in reply to Anonalzar
    Anonalzar:
    Unfortunately such attitude is not uncommon in the IT field.

    A company I previously worked at had no issue seeing horrible bugs in the application, given the fact that support would become valuable. We could just have enforced a few common best-practices and most of the issues would have disappeared "magically". Had "each developer has to test his own code or will be in trouble" been applied, we would have gained hundreds of hours of deployment ping-pong.

    However when I proposed such practices, I got an arbitrary "NO" response back. I no longer work there. After checking out of curiosity, I see that they are still producing questionable work. Good riddance. They have an excellent sales team however.

    Microsoft?

  • QJo (unregistered) in reply to Smug Unix User
    Smug Unix User:
    You can have wool for years, but lamb chops only once.

    You can have lamb chops for years if you have enough breeding pairs of sheep.

  • Charles F. (unregistered)

    TRWTF is not Googling for the code he asked Dean for. It's out there. I've found it. I've used it. It was pretty badly written, so I cleaned it up, but it works even if you don't.

    But it's nice to see someone rewarded for doing a good job for a change.

  • Anonymouse (unregistered) in reply to Didakos
    Didakos:
    A happy ending? :O

    Hold still, I'll go get you a towel... after the president's daughter is done using it to wipe up this horrible code.

    Captcha: nobis

    The nobis still knew more than the veteran.

  • fanguad (unregistered)

    Well written article. No extraneous obnoxious fluff. Believable and (bonus) happy ending. I hope we see more from Ellis.

  • Tammy (unregistered)

    TRWTF is waiting for someone else to do something he could've done with a few minutes of Googling.

    (Unless anonymisation replaced some much more complex task with SFTP.)

  • Miriam (unregistered) in reply to fanguad
    fanguad:
    Well written article. No extraneous obnoxious fluff. Believable and (bonus) happy ending. I hope we see more from Ellis.
    We usually get one article per month by her, from what I have seen so far in my time as TDWTF reader.
  • anonymous (unregistered) in reply to Black Bart
    Black Bart:
    Not the usual run of the mill WTF: I expected Aikh to be fired, but instead he was promoted for doing the right thing.
    He wasn't really. He quit and went to work for a company that appreciated his work.
  • Jacob (unregistered) in reply to QJo

    And, if you do it right, you can have lamb chops AND wool for many years. No need to choose just one or the other.

  • (cs)

    Where I work, there is one guy who is our "Ops" guy.

    As a developer, I'm tasked with figuring out issues in production. Often, the fix for the problem involves altering values in a table in the production database -- for example, adding a record that would trigger some process.

    Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    Who just opens up a sql window, pastes the script into it, and clicks the run button.

    That's his entire job -- wait for someone to send him a script, and run it.

    It's the same thing again -- his time is billed by his department; so if one of us were able to run the script, his services would not be needed, and his department would lose the revenue.

  • (cs) in reply to Dave
    Dave:
    Wait, nothing in his contract about leaving to go and work for the client?
    Quite apart from the fact that the story says that it is working for another business unit (which aren't usually legal entities and so can't enforce contracts like that on internal moves), it's also implied that Aikh is a junior; you don't usually bother with that sort of contract with a greenhorn as they're assumed to not know anything of value anyway.

    An assumption that's quite often wrong, as this story shows…

  • Jack (unregistered) in reply to QJo
    QJo:
    Besides, sitting in front of a terminal typing away manically made the service staff look *far* busier than merely sitting waiting for the computer to finish it's not-very-long run.
    Seriously, I think this is why Windows (and GUIs in general) became far more popular than the much more powerful CLI. If you get to "interact" with your computer 10 times a second, you will feel like you're doing something and the computer is responding to you. But if you hit enter and the computer goes off and thinks for an hour, it doesn't seem as, well, personal.

    Hint: if you can keep the CPU pegged for an hour (and it isn't stupid code) you're probably more productive than 50 mouse jockeys.

  • Henry (unregistered) in reply to DrPepper
    DrPepper:
    As a developer, I'm tasked with figuring out issues in production... Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    ... That's his entire job -- wait for someone to send him a script, and run it.

    It's called separation of duties. As a developer, you damn well better not have access to run code in production. That's how banks find themselves victims of multi-million dollar frauds.

    Indeed I seriously question your having read access to production data. Can you say "identity theft"?

    Hopefully he's not just pasting and running your script, though. He should also be doing a sanity check on what you've submitted, and logging it for posterity, which copy and paste seems not to accomplish. So TRWTF is not the existence of that guy, but that they appear (through your filters) not to have him doing enough.

  • Xaser (unregistered)

    Obligatory "Ellis Morning is great" post here.

    TBH though, this story scares me a bit since it's a definite WTF that I imagine happens -all the time- in the business world. Kinda feel extra-lucky now that I work with a consulting group that doesn't stick to that sort of practice.

    CAPTCHA: eros. I'll let your imagination fill in the gaps here.

  • smoof (unregistered)

    I don't buy it, Aikh’s manager would take the credit and get a bonus while throwing grenades into Aikh's employee record.

  • letatio (unregistered) in reply to Anonalzar
    Anonalzar:
    ....Good riddance. They have an excellent sales team however.

    So, what are we talking here? C cups?

  • (cs) in reply to QJo
    QJo:
    Smug Unix User:
    You can have wool for years, but lamb chops only once.

    You can have lamb chops for years if you have enough breeding pairs of sheep.

    Sheep is not multiply like rabbits. Also they eat a lot more than rats. So it is better to have lamb chops and make mince meat out of them.

  • Mr. AHole DBA Guy (unregistered) in reply to DrPepper
    DrPepper:
    Where I work, there is one guy who is our "Ops" guy.

    As a developer, I'm tasked with figuring out issues in production. Often, the fix for the problem involves altering values in a table in the production database -- for example, adding a record that would trigger some process.

    Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    Who just opens up a sql window, pastes the script into it, and clicks the run button.

    That's his entire job -- wait for someone to send him a script, and run it.

    It's the same thing again -- his time is billed by his department; so if one of us were able to run the script, his services would not be needed, and his department would lose the revenue.

    Yo DocPepper, you do realize that all sorts of compliance requirements state that devs will never have write access to production, correct?

    Also, that's not his only job, it's the end product that you only get to see. His job is a lot more involved than that. Design and managing solution's that gives you 5 9's uptime, meeting all the SLAs, perform capacity planning and growth, handle DR, and fix bad developer mistakes in prod are just some of the things 'ops guys' deal with on a daily basis.

    Anytime I've had a environment almost go down, you can thank the developers who think they are too good to follow IT best practices since it just slows them down.

  • usitas (unregistered) in reply to Henry
    Henry:
    As a developer, you damn well better not have access to run code in production. That's how banks find themselves victims of multi-million dollar frauds.

    Indeed I seriously question your having read access to production data. Can you say "identity theft"?

    But DBAs having access to production is perfectly fine, because they could never possibly commit fraud or identity theft? (And when did DrPepper even say he works at a bank in the first place?)

  • (cs) in reply to Jack
    Jack:
    Seriously, I think this is why Windows (and GUIs in general) became far more popular than the much more powerful CLI. If you get to "interact" with your computer 10 times a second, you will feel like you're doing something and the computer is responding to you. But if you hit enter and the computer goes off and thinks for an hour, it doesn't seem as, well, personal.
    I think you're trolling or an idiot. Here's a tip: GUIs are *not* the principal use case for tasks where the computer goes off and thinks for an hour. They're used for real-time data manipulation, not batch processing.
  • Anonymii (unregistered) in reply to usitas

    A DBA is somebody you entrust with the security of your data (and, in a more general way, the security of your company). That's part of their job, and when you hire one, you need to know they're somebody you can count on and trust.

    A developer isn't in the same position, at all.

  • Developer Dude (unregistered) in reply to Black Bart
    Black Bart:
    Not the usual run of the mill WTF: I expected Aikh to be fired, but instead he was promoted for doing the right thing.

    That's the true WTF - the rest of it is business as usual.

  • sagaciter (unregistered) in reply to Anonymii
    Anonymii:
    A DBA is somebody you entrust with the security of your data (and, in a more general way, the security of your company). That's part of their job, and when you hire one, you need to know they're somebody you can count on and trust.

    A developer isn't in the same position, at all.

    Because a developer could never maliciously or incompetently write code that damages your data or sends it somewhere it shouldn't.

  • Valued Service (unregistered) in reply to Anonalzar
    Anonalzar:
    Unfortunately such attitude is not uncommon in the IT field.

    A company I previously worked at had no issue seeing horrible bugs in the application, given the fact that support would become valuable. We could just have enforced a few common best-practices and most of the issues would have disappeared "magically". Had "each developer has to test his own code or will be in trouble" been applied, we would have gained hundreds of hours of deployment ping-pong.

    However when I proposed such practices, I got an arbitrary "NO" response back. I no longer work there. After checking out of curiosity, I see that they are still producing questionable work. Good riddance. They have an excellent sales team however.

    When the business starts with poor design, and develops its cashflow around supporting poor design, it is now forever stuck that way.

    The change has to come from the top.

    That's why I ask these questions in an interview. My first concern is, how much impact can I have on the processes. If I get any indication that I'll have zero impact, I move on. Even IF it's coder's paradise.

    Why?

    Because a management change will screw it all up.

    I look for the companies that ask their developers how development should be done, and get out of the way.

  • (cs) in reply to Tammy

    TRWTF is thinking that he should be responsible for doing this when it was someone else's task.

  • Valued Service (unregistered) in reply to Henry
    Henry:
    DrPepper:
    As a developer, I'm tasked with figuring out issues in production... Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    ... That's his entire job -- wait for someone to send him a script, and run it.

    It's called separation of duties. As a developer, you damn well better not have access to run code in production. That's how banks find themselves victims of multi-million dollar frauds.

    Indeed I seriously question your having read access to production data. Can you say "identity theft"?

    Hopefully he's not just pasting and running your script, though. He should also be doing a sanity check on what you've submitted, and logging it for posterity, which copy and paste seems not to accomplish. So TRWTF is not the existence of that guy, but that they appear (through your filters) not to have him doing enough.

    So, who are you going to have review the code?

    A non-developer wouldn't know what he's looking at. The most he can do is ask for more comments.

    A developer would be a developer.

    Ultimately you have to put a person with developer experience in charge of moving code to production.

    Accountants have access to identity information. Investors have access to identity information.

    Those guys would be pissed if you obfuscate account numbers and identities.

    You want a manager in charge of every little thing?

    I worked for one of those companies. The only reason they existed is that no one wanted to vie for the market share. Car Dealerships make HORRIBLE customers. They are worse as customers than they are as sellers. You think it's bad trying to buy a car from them... IT nepotism is the least of the problems.

  • Henry (unregistered) in reply to sagaciter
    sagaciter:
    Anonymii:
    A DBA is somebody you entrust with the security of your data (and, in a more general way, the security of your company). That's part of their job, and when you hire one, you need to know they're somebody you can count on and trust.

    A developer isn't in the same position, at all.

    Because a developer could never maliciously or incompetently write code that damages your data or sends it somewhere it shouldn't.
    No, exactly because they can write malicious or incompetent code, that's why they can't make their bad code go live. Somebody else has to do it. Somebody whose job it is to check what's being uploaded, and keep a record of what changed and who is responsible, so we can fire your ass and put you in jail if you try crap like that.

  • Henry (unregistered) in reply to Valued Service
    Valued Service:
    So, who are you going to have review the code?

    ...

    Ultimately you have to put a person with developer experience in charge of moving code to production.

    Correct. But that person works in ops and never writes code. Just reviews other people's work.

  • sino (unregistered) in reply to Henry
    Henry:
    No, exactly because they can write malicious or incompetent code, that's why they can't make their bad code go live.
    But DBAs can also write malicious or incompetent code, so why should they have access to production? You're begging the question here: "developers don't get production access, because we don't hire them carefully enough to trust them, because we don't give them production access so it doesn't matter", and inversely for DBAs. It's one thing if that's the way you do things in your company, but it doesn't make it a WTF for other people to do it differently.
  • (cs)
    “We’d be delivering something out of spec!”

    “It’s what we can deliver on-time and on-budget.”

    Software development in a nutshell.

  • TenshiNo (unregistered) in reply to Dave

    The "non compete" clauses that prohibit you from working for other companies in the same field for X number of years after you leave a company have been repeatedly found (at least in the US) to be unenforceable. I understand the intent behind the clauses, but I have to agree that they aren't really feasible, especially when you're just working for a company that does custom software for clients.

  • Jay (unregistered)

    The in-house IT departments that I have worked for have never had a problem of not having enough to do. They've always had long waiting lists of projects.

    A friend of mine once told me that at his company, every request for IT services was given a "priority" from 1 to 10, with 1 being the highest priority. He said that at meetings people would spend hours arguing about whether a given project should be priority 3 or priority 4, and departments would battle to get their pet project boosted a step or two. And for all that, he said, in all the years he worked there, they never actually worked on any project that was less than priority 1.

  • TenshiNo (unregistered) in reply to Henry
    Henry:
    DrPepper:
    As a developer, I'm tasked with figuring out issues in production... Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    ... That's his entire job -- wait for someone to send him a script, and run it.

    It's called separation of duties. As a developer, you damn well better not have access to run code in production. That's how banks find themselves victims of multi-million dollar frauds.

    Indeed I seriously question your having read access to production data. Can you say "identity theft"?

    Hopefully he's not just pasting and running your script, though. He should also be doing a sanity check on what you've submitted, and logging it for posterity, which copy and paste seems not to accomplish. So TRWTF is not the existence of that guy, but that they appear (through your filters) not to have him doing enough.

    I agree with the evaluation of the "Ops" guy's position, but not with not giving at least read access to production. If you are expected to support the production environment for the code you wrote, then you need at least read rights.

    It would be different if the Ops role also handled production support.

    When I first started this job, they didn't want me to have read rights in production so, every time a bug report came through, I would have to type of a query and send it to my boss. He would then run it and send me back a CSV file. Then I'd send him another query and he'd send back another CSV file. That lasted a few weeks until finally he just put in a request to have a read-only account created for me to use.

    It's almost impossible to troubleshoot a system if you're literally blind to what it's doing.

    Of course, all this is barring have a proper production support instance, which is finally getting setup here.

Leave a comment on “Manual Automation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article