• who? me? no! (unregistered)

    DROP PROCEDURE FRIST

  • bvs23bkv33 (unregistered)

    DROP FRIST COMMENT CREATE FRIST COMMENT

  • TheCPUWizard (unregistered)

    DROP MANAGEMENT;

  • Derp (unregistered)

    I'm sure that there's at least one overseas (we all know exactly where that means) code sweatshop that produces quality work, but I doubt any of us will ever see it.

  • (nodebb)

    This reminds me of an issue I see at my job. Our coding standards state all code needs to be reviewed, we mainly have one guy (VERY experienced senior developer) do them. Most of the time he rejects the outsourced team's code because it doesn't follow our standards at all (after they have been aware of it for 2+ years) or is just wrong in many cases. Often, we find these scripts deployed to production anyways. And as a result management doesn't really enforce the standards or use them themselves. So we have standards that aren't enforced at all, and are typically circumvented, and another manager's team doesn't use them at all even though said manager approved them and demanded changes that were incorporated (e.g. no underscores in function/procedure names, tabs instead of spaces)

  • Quite (unregistered)

    My father worked in the QA department of a heavy metals outfit (gold etc.) where his task was to assay the product and make sure its content was of an adequate purity (I believe they may have produced ingots or something). Came the time when they needed to cut costs (dmn the fact that the owner of said outfit was pretty dmn rich, and was in fact the man whom Ian Fleming based his Goldfinger character on). And which was the department to get axed? Yep, you guessed, QA. Well, they weren't totally axed, but they were seriously cut down, and there were few staff left. Of course, this meant the work took that much longer to accomplish. It's taking too long, can you speed up the process? No, that would mean compromising the QA. Oh, well can you just skip some of the testing, just rubber-stamp it as being tested? Because we've got to get this stuff out of the door. Cue my father resigning. He spent a lot of time in the garden for a few months, and our diet consisted of what he could (figuratively) pull out of the ground. I really came to hate broad beans.

  • Oliver Jones (google)

    Maybe it's the exception that proves the rule. But I worked with a krewe from India for a while who did a great job.

    What did it take? Well, their people were smart and got things done. They paid attention to what we were trying to accomplish.

    And for our part, we treated them with respect. we sent somebody to visit them once a year. We brought them small gifts, like personalized iPods (this was a while ago).

    We worked hard to explain our project, and worked hard to overcome their cultural reluctance to say "I don't get you" when they didn't understand. When their work product was good, we told them so. When it had problems, we explained what was wrong in causal terms. For example, we said "if you recreate the sp from scratch, you also have to do the grants. It's up to you, but the grants are hard to get right."

    We did a Skype call with them each work day in the morning our time, evening their time.

    Another factor in our favor: these guys had their tech center in Bhubaneswar in Odisha in eastern India, not in Bengaluru (fka Bangalore). I haven't worked with a Bengaluru company, but I know our team members stayed on the job long enough to develop real understanding of our space. The only exception was tragic: our QA manager was killed when a bus hit his motorcycle on his morning commute.

    So, overseas devs are like anybody. They want to do a good job, and they need time to learn. They fail when mgmt treats them like a silver bullet.

  • P (unregistered) in reply to TheCPUWizard

    Yep, definitely one management team that will put the company out of business...

  • P (unregistered) in reply to Derp

    That's because this team will charge too much for the morons in management.

  • Anonymous Coward (unregistered) in reply to Oliver Jones

    Definitely the exception. The oursourced teams that I engage with at [[large financial organisation based in Canary Wharf]] are mostly abysmal.

    No pride, no real knowledge, and no desire to learn.

    And that's the developers. The ones who support the business are even worse.

  • Dave (unregistered)

    Any offshore team can only ever be as good as the instructions that are communicated to them. As Oliver observed, some of them are very good indeed. Many others are poorly led and some should be put out to grass.

    What's not clear is whether the template was handed over with the instruction to "follow this template" or whether the template contained useful comments to explain why the different parts of that template exist.

    A lot of in house development is trying to apply knowledge of the non-IT business functions to put context around poorly defined requirements. Without that business knowledge an offshore team is at the mercy of that poorly defined requirement in a 2nd language passed on through numpty-chumpty intermediaries. It's amazing they produce anything!

  • Jonathan (unregistered)

    If management is so disconnected on the cost of poor quality, then it's possible a change in communication strategies will help.

    At the very least they should have a QA environment on which they test deploys received from the outsourced team. Any failure to deploy to the test environment should be reported to management perhaps with the reminder to the effect of "It's good thing we tested first, or their code would have bought down our live system!" No manager in their right mind would have something pushed to live which they can see for themselves is not working.

    In regards to reporting to management on code reviews, they probably can't accept answers like "we can't deploy this, it's just too bad" and they most likely can't read code to assess the truth of this. Instead present them with things like: "The technical debt incurred by the submitted code is x, it may not bite us today, or even tomorrow, but one day eventually, everything will collapse and it will cost 10 times as much to fix then as it would to just fix it now, on top of the downtime. If we accept this now, we will have to pay for it later."

    Ideally one should have managers that understand software, but failing that then the next best thing you can do is effectively communicate with them in a way they can understand for themselves the negative impacts of their decisions. Failing that, leave, or otherwise CYA and have all your warnings in writing for that day when the technical debt collector arrives heralded by the production system failing.

  • (nodebb)

    Lay off the contractors indeed.

  • Dave (unregistered)

    I won't say that in my experience 'bad outsourcing' always means bad management by the party buying in the service - because I'm sure there must be at least some exceptions. But almost always? Certainly.

    Managing outsourcing requires specific skills and experience to do well, just like most jobs. If an organisation doesn't have those skills on board - usually because they've been doing things in-house until now - then they're going to struggle to get the contract terms and oversight right. If they don't get those right, they're either going to pay for something they don't need, or not get what they pay for - or both, in a real clusterfuck.

  • Martin (unregistered)

    Am I the only one who see the unicorns in this website?

  • Brad Wood (google)

    Honestly, is this still the case? I loved Sql Server, but 'alter' should alter if exists OR create. That would eliminate so much headache.

  • Brian Parker (google) in reply to Brad Wood

    In a service pack to SQL Server 2016, they added the much-requested "CREATE OR ALTER ..." statement.

  • MiserableOldGit (unregistered) in reply to Dave

    I agree, most places I've seen going the outsourcing route do so because all their IT projects go over budget, over time and fail to deliver what everyone wanted. Unsurprisingly, outsourcing tends to mean they just get a greater quantity of shit code per dollar, still fail to hit deadlines and cost ceilings, and the gap between expectations and delivery widens.

    There are competent outsourcing partners and rubbish ones, but the problem I've been witness to is the firms themselves having major management and communication issues and thinking sending it all to Elbonia is a magic bullet. They are lucky if they manage to select a good outsource partner (because most firms like that won't), but even then it's not usually enough.

    I once spent about 4 months practically living in a hotel on the other side of the country to help some outfit get our ill-conceived ecommerce overhaul to limp into life. That was originally a 3 month project (took about 7) budgeted at around $25k (god knows the costs, but travel and subsistence alone probably cost that) and we damn near bankrupted them forcing them to deliver. I remember sitting there with my manager when they submitted their bid and trying to persuade them to have a good hard think about it, dropping all the hints we could about our firm's shit business processes, inflexibility, and flip-flop decision making and inability to actually state a clear requirement. We should have rejected the bid. Well, I should've left the idiots three years earlier than I did.

  • Parametamolcil (unregistered)

    TRWTF: Naming your kid after a TV.

  • not a robot (unregistered) in reply to Derp

    overseas

    You mean in murica?

  • Carl Witthoft (google) in reply to Parametamolcil

    Better than naming your kid "Nadir"

  • eric bloedow (unregistered)

    i can't help but think about a short story i read about how an official software update to a Playstation (i forget which model) PERMANENTLY RUINED IT! "bricked" it. not just him, either, HUNDREDS of them! THAT it how stupid it is to release stuff without proper testing!

  • Yazeran (unregistered) in reply to Brian Parker

    Yep. That's (one of the reasons) why I have never regretted using postgresql. For as long as i have used it (10+ years) it have had

    CREATE OR REPLACE FUNCTION ....

    which makes creation (or altering) functions trivial. The only caveat is that you can risk overwriting an existing function.

    However if you use even slightly descriptive function names that is not really an issue. (I would also suggest adding comments in the function description so that the next developer (that is yourself in 12 months!) will have a chance to figure out what it is suppose to do).

    Of cause if you use function names like proc_17 you get what you deserve when you accidentally overwrite that with something else...

  • Herby (unregistered)

    As far as coding standards go for "outsourced" work, it boils down to something like:

    Here are our coding standards. Please code to them. We will only pay you if you meet our coding standards. We have a checker that verifies your work. Please quote.

    The problem with the "outsourcing" contracts is that they rarely have any enforcement of standards on the "outsourcer", which usually leads to the disaster later on.

    Caveat Emptor.

  • Jerky LLC Owner (unregistered)

    function makeMonies() { do { try { $llc = new ThrowAwayCompany(); $llc->bidOnBigContract(offer='LOWBALL'); $llc->hireCoder(skill=0, wage=0.01); while(1) { $llc->payMeBigSalary(); $llc->generateCodeForCustomer(code_review=false, testing=false, make_sure_it_works=false, onCustomerComplaintCallback = $generateManagementSpeakRunAround); } } catch(OutOfBusinessException) { // pass } } while($profits); }

  • enourmous howard (unregistered) in reply to DocMonster

    You should find a different place to work. That would be very frustrating.

  • Gummy Gus (unregistered)

    A while back a certain company outsourced their life-critical medical device QA to India. They congratulated themselves as to their code quality,as there was rarely a bug report from that subcontinent. The self-cheering died down a bit when they sent off a release for a 72-hour test, and the results came back the next morning.

  • Adam Hawkes (google)

    "custmoer" ? I don't know, maybe the joke is on me.

  • Barf4Eva (unregistered)

    oh god no... not DROP and CREATE in the same deploy script.. :|

    Funny, we do the same thing here at my large corporation and don't have a problem. Likely cause the scripts are DROP, CREATE, and GRANT, separated logically by GOs. I imagine lots of people do this at different big companies.

    Although I'm interested in the CREATE OR ALTER statement! Props to those who made mention of it. I'll use that for scripts for my personal projects from now on.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    DROP ThatGun AND WalkAway FROM TheDesk;

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to eric bloedow

    Are you sure you aren't confused with the PS3 clock bug? If I recall correctly, this was even a bug in the clock chip itself where it computed leap years incorrectly, confusing the PS3's operating system by reporting a date of February 29, 2010.

    On the other hand, the PSP had a problem where if you hacked it and then mounted its system partition with a computer that liked to drop a bunch of useless files onto volumes (coughOSXcough), it would trigger a bug in the filesystem driver and corrupt the partition, bricking it.

    (Later it wouldn't be a total brick, thanks to someone getting a PSP returned from service with a memory stick labeled "JIGKICK" left inside it. Once the memory stick boot process was reverse-engineered, the original PSP-1000 was wide open.)

  • (nodebb) in reply to Parametamolcil

    The OP doesn't seem to believe it, since his name is in bold and a bit later it's in "quotes".

  • (nodebb) in reply to Oliver Jones

    For example, we said "if you recreate the sp from scratch, you also have to do the grants. It's up to you, but the grants are hard to get right."

    What is so hard about grants? They are in a script in your version control, right?

  • Casey C. (unregistered)

    Hmm.... "We did the needful..."

    I am 99.9999999999999999999999999999999999999999999999999999999999999999999999999999999% positive where your offshore team is located. At the same time, I am very jealous of the work that was received. Much higher quality than the crap I've seen recently.

  • RichP (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    DROP thatgun; SELECT thecannoli;

  • Barf4Eva (unregistered)

    Dems a lot of assumptions there, Zenith. :)

    But point taken on dropping and creating. Makes sense to me. But we have a lot of controls in place, much like the scenario you allude to in your last sentence. Never hurts to be safe, I guess. At the same time, just because you did an alter and not a drop doesn't mean everything is peachy. Could be someone introduced something just as tragic in the altered version of the stored procedure. :)

    You can always find fault somewhere. Sometimes just not worth too much thought or the thought could be better spent elsewhere

  • Thargy (unregistered)

    @Zenith,

    just back from a holiday Zenith, so glad to see you're in there punching away - sadly aiming at the wrong target. The comments about CREATE, DROP ALTER (or whatever else it may be) are ALL entirely wrong.

    If - and obviously in many cases it's 'because' - you don't have genuine build control, such statements are never necessary. If you have a known guaranteed database build, and want to change it to something different, you just issue the minimum necessary statements to do so. Although oracle for example has the "CREATE OR REPLACE" syntax, after 25 years I never ever use it. If I don't know whether or not something exists in a database for which I'm answerable, then I am just not doing my job properly. I must absolutely always know whether I need a CREATE statement - or not. Using implicit conditional logic just shown incompetence. Numpties who don't appreciate the significance of this are cordially invited to book themselves onto an introductory course about database administration.

    W.R.T your comment about "When 90% of the application's logic is in the database (another WTF)" this too is wrong. Applications should either have the code 100% responsible for the data, or the RDBMS 100% responsible - anything else means you can get into a "he said she said" argument. Only having one arse to kick is always a good thing and stops buck passing.

    Oh, and just so you can flame away at me, see https://www.youtube.com/watch?v=8jiJDflpw4Y, https://www.youtube.com/watch?v=eE5yAMmS1WM and https://www.youtube.com/watch?v=odf_jxK7lDA for why it just has to be the database. When you have cogent, verifiable arguments to the contrary, substantiated with reproducible independently verifiable evidence, I'd be very much interested in what you have to say.

    Until then, I go back to work tomorrow, having had a wee vent and a tiny rant, ready for that which the world will throw at me.

    T

  • Zenith (unregistered) in reply to Thargy

    You're really going to defend having your stored procedures run 30 screens worth of IF/ELSE branching, WHILE loops, and calls to other stored procedures with numerous account impersonations and calls to the command line? In a language that won't even check if 90% of the stuff you're calling or referencing exists before executes the CREATE/ALTER? Much be nice to go "b-b-but the databases!" or "m-m-more hardware is needful!" every time your copypasta code performs poorly or not at all. Talk about passing the buck. I'd say "turn off YouTube and go back to work" but any place you're employed at is better off with you as far away from real work as possible.

  • Zenith (unregistered) in reply to Barf4Eva

    I know. In fairness, the template supplied was a better-than-nothing sort of deal. When I was a full-stack developer, I wouldn't have needed it because I knew how everything worked together, had proper access, and actually documented stuff. These developers are very secretive and don't have any processes in place. Ask four of them what time period a sprint covers and you get five different answers and none of them right. So when they send a batch of code for review, it could be anything...except what TFS reports (because that would be right). We had been trying to get automated builds set up but they're so confused that it's going nowhere. Our Microsoft rep literally gave up. Every year it's the same recommendations and every year it falls on deaf ears. People here probably won't agree but many of these tools are designed to cover for lousy developers (lots of layers with a "do what I want" button at the top that hopefully they can push without screwing up).

    https://media.giphy.com/media/8Oh4uSG2NkiVW/giphy.gif

    None of these applications is really that complex except for purposeful obfuscation. The servers are in another state, half managed by different contractors and half managed in-house with policies dictated elsewhere. The software is cobbled by foreign contractors browsing expert-sexchange and the JS wing of github. DBAs are just supposed to keep SQL Server up. And get called when the duhvelopers write an infinite loop or fill the hard drive with a billion rows of "user moved the mouse two pixels down" logging or run out of sockets from their app pool or a firewall rule broke something or Outlook stopped or it's raining outside.

    And then this Blargy or whatever troll wants to run its mouth off about passing the buck? If I had any say, it and its coworkers would be on the street yesterday. It should consider itself lucky that I have only responsibility and not authority.

Leave a comment on “Drop it Like it's a Deployment”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article