• Black Bart (unregistered)

    using SQL Server's GETDATE()

    What did I miss? It does use GETDATE(), although in a bizarro fashion. I'd question whether timezones were properly accounted for though.

  • The_Assimilator (cs)

    This isn't necessarily incorrect. If there is the possibility of dealing with timestamps from different timezones, it's entirely possible that getdate() may not be adequate. Changing a single view to return a different date is a lot less effort than doing a codebase-global search+replace.

    As per usual the article is short on detail, so there's no way to tell if this really is a WTF, or some forward thinking.

  • DilbertLookaLike (unregistered) in reply to The_Assimilator
    The_Assimilator:
    This isn't necessarily incorrect. If there is the possibility of dealing with timestamps from different timezones, it's entirely possible that getdate() may not be adequate. Changing a single view to return a different date is a lot less effort than doing a codebase-global search+replace.

    As per usual the article is short on detail, so there's no way to tell if this really is a WTF, or some forward thinking.

    The real WTF is using forward thinking in an Offshore context... Oxymoronic to say the least. (never had any positive experience with offshore to India or any other low wages/low quality country)

  • pjt33 (cs)

    TRWTF is working out which notifications haven't been sent by comparing dates rather than by using a Boolean (ok, bit) column which is updated by the notification sender.

  • steenbergh (cs)

    Perhaps an attempt to abstract away the database-specific functions? As to protect the code from a possible (though improbable...) move to Oracle or another platform? In such a scenario, only the GetDate view has to be rewritten.

    I have actually seen this done before. It was not a pretty sight...

  • Remy Porter (cs) in reply to The_Assimilator

    But that assumes that every place that's using the view should automatically be getting the new behavior. Instinctively, you'd say, "yes", but I wouldn't be so confident- these are dates after all.

    It reeks of premature refactoring. "I have no idea what I'm going to change later, so let me hide anything that could possibly change," which is a formula for unreadable, incomprehensible, and impossible to support code.

    Even if we ignore all of those problems, there's still the fact that you're turning a non-deterministic function result into a view for chrissakes. That is completely indefensible design. Views are a way to present data contained in entities. As such, the data in a view shouldn't change unless the underlying entities have changed.

    So even if we ignore the premature refactoring problem, it's still a WTF- they should have created a UDF that contains the custom logic (or the hooks for the custom logic, since there isn't any custom logic yet). So yeah, this is incorrect. It is completely incorrect. The fact that anybody even thinks this is correct makes me sympathize with the DBAs that sneer at developers.

  • Barry the Builder (unregistered)

    from what I remember, you couldn't use GETDATE in a UDF in sql 2000 as that would make it non-deterministic and UDFs had to be deterministic so the options were pass in the date as a parameter or use something like this to get it

  • Dave (unregistered) in reply to Barry the Builder
    Barry the Builder:
    from what I remember, you couldn't use GETDATE in a UDF in sql 2000 as that would make it non-deterministic and UDFs had to be deterministic so the options were pass in the date as a parameter or use something like this to get it

    Point well missed. Good work!

  • Remy Porter (cs) in reply to Barry the Builder

    That doesn't really change anything. If you need to do custom date processing, you should do that in a UDF. If SQL Server puts a constraint on your UDF that the date has to be passed as an input, then just pass it as an input.

  • Barry the Builder (unregistered)

    there are a number of examples on various sites on how to work with getdate in sql 2000 udfs and they all show the same 2 methods. one passing it in as a parameter and the other using a view. guessing the offshore guys went for the lazy option and used a view. This is actually a fairly common thing when development has been done using sql 2005+ and has been released onto a 2000 production environment. easier to change a single function to use a view to get the date than change all the procs that use that function to pass in the date. not that that means it's the 'best' way to do it mind

  • Smug Unix User (unregistered)

    This is actually pretty handy if you have all your views route date logic to a single place you can change the view "select getdate() Now" to any date you want. You could even write a case statement to switch the date based on the CURRENT_USER so multiple users can test in the same database with different dates.

  • anon (unregistered) in reply to pjt33
    pjt33:
    TRWTF is working out which notifications haven't been sent by comparing dates rather than by using a Boolean (ok, bit) column which is updated by the notification sender.

    I'd rather have the client send in the ID of the last message it succesfully processed.

  • Nagesh (cs) in reply to Smug Unix User
    Smug Unix User:
    This is actually pretty handy if you have all your views route date logic to a single place you can change the view "select getdate() Now" to any date you want. You could even write a case statement to switch the date based on the CURRENT_USER so multiple users can test in the same database with different dates.

    Agreed

  • nobulate (unregistered)

    + A better way of abstraction The date function is built into the business layer (database views) to make provision for any future changes (scope creep) that may present themselves (silent sprints) during the product lifetime (next week tuesday).

    + A time machine! Furthermore, just amend the view to calculate dates into the future - making an application to withstand the test of time (but not the unit tests of time).

  • QJo (unregistered)

    The real WTF: "He marked the code review failed and re-opened the change request."

    IMO he should have opened a dialogue asking them to explain "Why not just do it like this?" rather than just slapping "failed" on it.

    In that way, the offshoring team have a chance to put their point of view across, and JH then has the opportunity to teach them of the dangers of over-engineering and the joys of YAGNI.

    As his manager, I would be calling into question his deliberate failure to at least try and make the partnership with the offshore team function adequately. He may not like it, but this is where he is, and these are the parameters in which he is expected to work. Treating the offshore team with such abruptness and dismissiveness is counterproductive on all possible levels, and in the end JH comes across as being a bit of a dick.

  • Bob (unregistered) in reply to Smug Unix User
    Smug Unix User:
    ...if you have all your views route date logic to a single place you can change the view "select getdate() Now" to any date you want.
    Serious question: is *anyone* aware of a DB platform that takes testing seriously? You always have to jump through hoops, like in this case.

    Google tells me that SQL Server does have unit tests, kind of: "If you open [in Visual Studio] a solution that contains both a database project and a database unit test project from a previous version of Visual Studio you will be prompted to upgrade the database project. You will not be prompted to upgrade database unit test projects, which must be upgraded manually."

    That's taking testing seriously, yes indeed.

  • Anon (unregistered) in reply to QJo
    QJo:
    The real WTF: "He marked the code review failed and re-opened the change request."

    IMO he should have opened a dialogue asking them to explain "Why not just do it like this?" rather than just slapping "failed" on it.

    In that way, the offshoring team have a chance to put their point of view across, and JH then has the opportunity to teach them of the dangers of over-engineering and the joys of YAGNI.

    As his manager, I would be calling into question his deliberate failure to at least try and make the partnership with the offshore team function adequately. He may not like it, but this is where he is, and these are the parameters in which he is expected to work. Treating the offshore team with such abruptness and dismissiveness is counterproductive on all possible levels, and in the end JH comes across as being a bit of a dick.

    If it was something complex which was an optimization issue, this makes sense.

    Otherwise, you're asking him to do their job for them. I doubt he's getting paid to do both his own job and the jobs of everyone else.

    You must be a manager, since this is Modern Management Thinking: Pay someone who can't do the job to make it look like you've actually got enough people on the project, then demand that your existing developers do both their own work AND the work of the offshore team.

    Then collect your bonus for 'reducing expenditures.'

    Burning out your devs is fine, I'm sure you'll be able to find more offshore replacements.

  • Joe (unregistered)

    In my 20+ years in the IT industry I've NEVER seen outsourcing work. It ends up costing more money having to rewrite the shitty code written by monkeys.

  • Valued Service (unregistered) in reply to QJo
    QJo:
    The real WTF: "He marked the code review failed and re-opened the change request."

    IMO he should have opened a dialogue asking them to explain "Why not just do it like this?" rather than just slapping "failed" on it.

    In that way, the offshoring team have a chance to put their point of view across, and JH then has the opportunity to teach them of the dangers of over-engineering and the joys of YAGNI.

    As his manager, I would be calling into question his deliberate failure to at least try and make the partnership with the offshore team function adequately. He may not like it, but this is where he is, and these are the parameters in which he is expected to work. Treating the offshore team with such abruptness and dismissiveness is counterproductive on all possible levels, and in the end JH comes across as being a bit of a dick.

    So much this.

    Everyone knows it stinks. And in most cases, the management does too, but they're bound by some measure of the echelon to make a cut somewhere.

    If you look at it as a challenge, and define it within the parameters of your job description on your next review, you'll get some serious cred.

    And if you're looking to move up. Management's job is to get the best productivity out of people. This is prime training grounds.

    The OP's solution is arrogant at best, and downright counter-productive at worst. All he is going to get is more bad code. And when other programmers show that the offshoring is a failure by trying to make it work, he looks like the prime target for the next layoff.

    In short, the OP here is nothing more than a programmer with a job, not a engineer with a career.

  • QJo (unregistered) in reply to Joe
    Joe:
    In my 20+ years in the IT industry I've NEVER seen outsourcing work. It ends up costing more money having to rewrite the shitty code written by monkeys.

    We're making it work.

  • TGV (cs) in reply to Valued Service
    Valued Service:
    In short, the OP here is nothing more than a programmer with a job, not a engineer with a career.
    Such ghastly HR drivel! Go back to your hell of uselessness!
  • Smitty (cs) in reply to Valued Service
    Valued Service:
    QJo:
    The real WTF: "He marked the code review failed and re-opened the change request."

    IMO he should have opened a dialogue asking them to explain "Why not just do it like this?" rather than just slapping "failed" on it.

    In that way, the offshoring team have a chance to put their point of view across, and JH then has the opportunity to teach them of the dangers of over-engineering and the joys of YAGNI.

    As his manager, I would be calling into question his deliberate failure to at least try and make the partnership with the offshore team function adequately. He may not like it, but this is where he is, and these are the parameters in which he is expected to work. Treating the offshore team with such abruptness and dismissiveness is counterproductive on all possible levels, and in the end JH comes across as being a bit of a dick.

    So much this.

    Everyone knows it stinks. And in most cases, the management does too, but they're bound by some measure of the echelon to make a cut somewhere.

    If you look at it as a challenge, and define it within the parameters of your job description on your next review, you'll get some serious cred.

    And if you're looking to move up. Management's job is to get the best productivity out of people. This is prime training grounds.

    The OP's solution is arrogant at best, and downright counter-productive at worst. All he is going to get is more bad code. And when other programmers show that the offshoring is a failure by trying to make it work, he looks like the prime target for the next layoff.

    In short, the OP here is nothing more than a programmer with a job, not a engineer with a career.

    In my experience with offshore, asking 'why was this done this way?' is typically met with crickets.

    Asking 'have you considered X approach instead, why or why not?' is typically met with crickets plus the work being re-implemented in an extremely literal interpretation of X approach, regardless of whether X approach is actually a good solution.

    I agree that the OP should have tried to start a a dialogue with the offshore team. However, the story doesn't mention whether he's repeatedly attempted the fruitless and soul-sucking chore of trying to get an offshore team to open up in the past, so I have to cut him some slack.

  • The Janitor (unregistered) in reply to QJo
    QJo:
    Joe:
    In my 20+ years in the IT industry I've NEVER seen outsourcing work. It ends up costing more money having to rewrite the shitty code written by monkeys.

    We're making it work.

    This is a highly dubious claim, to say the least. I've seen too many things like

    if(x<250000 && x>1000000)...

    to really take such statements without huge grains of salt.

  • Loren Pechtel (cs)

    This is more testable than the direct version.

    I rather suspect that's due to blind adherence to rules rather than because it was actually used for testing, though.

  • QJo (unregistered) in reply to The Janitor
    The Janitor:
    QJo:
    Joe:
    In my 20+ years in the IT industry I've NEVER seen outsourcing work. It ends up costing more money having to rewrite the shitty code written by monkeys.

    We're making it work.

    This is a highly dubious claim, to say the least. I've seen too many things like

    if(x<250000 && x>1000000)...

    to really take such statements without huge grains of salt.

    I'm afraid I can't answer for the appalling management in the companies that you work for that have caused your experience to be jaded (unless you're just exhibiting nationalistic chauvinism, of course), but in the experience of me and my colleagues, if you do the job properly it works well.

    All I hear against outsourcing on this site is the ranting of racists and xenophobes.

  • Mike (unregistered) in reply to QJo
    QJo:
    All I hear against outsourcing on this site is the ranting of racists and xenophobes.

    You may call it racist, I judge by objective measure of code quality and meeting specifications.

    We have been customers (victims) of offshoring. I assume by your stance that you are a supplier (perpetrator) in an offshored relationship?

    You suggest that if hte offshore relationship doesn't work out it's the fault of the customer. Who is paying who in that relationship? So if I hire a plumber and he connects the gas to the hot water and leaves the cold water dripping over the carpet then in your world that would be my fault for not managing the relationship preperly?

    You are right in one sense, it is the fault of our management for making hte decision to go offhoring in the first place. The sooner we stop this stupid insanity the better.

  • Development Manager (unregistered) in reply to Valued Service

    As a manager, it is my job to train the internal dev teams that work on my projects, and teach them about best practices, new technologies, professional ethics, etc.

    This is why internal resources are more expensive. It's expected that you are paying for their career growth and expertise development.

    When you move them offshore as an outside vendor, it is no longer my responsibility to train them to do their jobs. You wanted to reduce costs and risks by having an interchangeable outside team you can hold accountable? Well, then hold them accountable. Their training and career development needs to come out of their profits, not mine.

  • englebart (unregistered)
    Comment held for moderation.
  • chubertdev (cs)

    This is very, very high quality offshore code.

  • odio (unregistered) in reply to chubertdev
    chubertdev:
    This is very, very high quality offshore code.
    Never thought I'd see the words 'quality' and 'offshore code' in the same sentence. :-/
  • chubertdev (cs) in reply to odio
    odio:
    chubertdev:
    This is very, very high quality offshore code.
    Never thought I'd see the words 'quality' and 'offshore code' in the same sentence. :-/

    It's a relative term. The offshore code that I've worked with was a prime example of how to do everything wrong.

  • Joe (unregistered) in reply to QJo

    Like you said "If you do the job properly it works well". I've never seen the job done properly the first time.

    Iteration 1: Send specs to India (wait 12 hours for results because of timezone difference) Iteration 2: Code is totally fucked up. Send emails to outsourcing company. (wait 12 hours) Iteration 3: Still not working. Send emails to outsourcing company. (wait 12 hours) Iteration 4: Still not working. Send emails to outsourcing company. (wait 12 hours) Iteration 5: Still not working. Send emails to outsourcing company. (wait 12 hours) Iteration 6: Still not working. Send nasty emails to outsourcing company. (wait 12 hours) Iteration 7: Still not working. Send emails to outsourcing company telling them to use senior developers instead of monkeys. (wait 12 hours) Iteration 8: Still not working. Send emails to outsourcing company threatening lawsuit. (wait 12 hours) Iteration 9: Still not working. Just fucking give up at this point (wait 10 days)

    Oh it finally works! Wow it saved the company sooooo much money

  • Joe (unregistered) in reply to Development Manager

    No - you pay extra to get the job done right the first time and not have to wait 10x the amount of time it would take to get it done in house.

  • Loose Bree (cs) in reply to nobulate
    nobulate:
    ...the unit tests of time
    *yoink* I'm stealing this!
  • Nagesh (cs) in reply to Joe
    Joe:
    In my 20+ years in the IT industry I've NEVER seen outsourcing work. It ends up costing more money having to rewrite the shitty code written by monkeys.
    Spoken like a true hater
  • Planar (cs) in reply to Nagesh
    Nagesh:
    Spoken like a true hater

    You're a fake Nagesh, there is no grammar mistake in your sentence.

  • Joe (unregistered) in reply to Nagesh

    Yep it's true. I hate shitty code.

  • Old Man (unregistered) in reply to anon
    pjt33:
    TRWTF is working out which notifications haven't been sent by comparing dates rather than by using a Boolean (ok, bit) column which is updated by the notification sender.

    This, not

    anon:
    I'd rather have the client send in the ID of the last message it successfully processed.

    this.

    You assume that every message up to the last, single ID sent in was successfully processed. That is a wrong (and sometimes dangerous) assumption!

    CAPTCHA: We learn from out EROS, or we repeat them for different employers!

  • Joeseph (unregistered) in reply to Joe
    Joe:
    Like you said "If you do the job properly it works well". I've never seen the job done properly the first time.

    Iteration 1: Send specs to India (wait 12 DAYS for results because of timezone difference) Iteration 2: Code is totally fucked up. Send emails to outsourcing company. (wait 12 DAYS) Iteration 3: Still not working. Send emails to outsourcing company. (wait 12 DAYS) Iteration 4: Still not working. Send emails to outsourcing company. (wait 12 DAYS) Iteration 5: Still not working. Send emails to outsourcing company. (wait 12 DAYS) Iteration 6: Still not working. Send nasty emails to outsourcing company. (wait 12 DAYS) Iteration 7: Still not working. Send emails to outsourcing company telling them to use senior developers instead of monkeys. (wait 12 DAYS) Iteration 8: Still not working. Send emails to outsourcing company threatening lawsuit. (wait 12 DAYS) Iteration 9: Still not working. Just fucking give up at this point

    Oh it finally works! Wow it saved the company sooooo much money

  • Coyne (cs) in reply to The Janitor
    The Janitor:
    QJo:
    Joe:
    In my 20+ years in the IT industry I've NEVER seen outsourcing work. It ends up costing more money having to rewrite the shitty code written by monkeys.

    We're making it work.

    This is a highly dubious claim, to say the least. I've seen too many things like

    if(x<250000 && x>1000000)...

    to really take such statements without huge grains of salt.

    So, out of curiosity, which was it: Just plain old idiot-broken? Or did they overload the && operator?

  • The Dead Code (unregistered) in reply to Coyne
    Comment held for moderation.
  • the way these mods are fucking gay. (unregistered)

    fuck you mods deleting my post

  • immibis (cs)

    Then don't make shitty posts?

  • QJo (unregistered) in reply to Mike
    Mike:
    QJo:
    All I hear against outsourcing on this site is the ranting of racists and xenophobes.

    You may call it racist, I judge by objective measure of code quality and meeting specifications.

    We have been customers (victims) of offshoring. I assume by your stance that you are a supplier (perpetrator) in an offshored relationship?

    You suggest that if hte offshore relationship doesn't work out it's the fault of the customer. Who is paying who in that relationship? So if I hire a plumber and he connects the gas to the hot water and leaves the cold water dripping over the carpet then in your world that would be my fault for not managing the relationship preperly?

    You are right in one sense, it is the fault of our management for making hte decision to go offhoring in the first place. The sooner we stop this stupid insanity the better.

    What we did was opened our own office offshore, recruited and trained our personnel ourselves, and built up close personal relationships with our offshore staff. Those staff travel here on occasion "for the experience" mainly, and for particularly challenging projects that require extra physical proximity for managemental purposes.

    In turn, the project office in the American continent use the staff in this office (European based) as resource on their own projects as needed. It all depends on what particular skill mix is needed.

    Admittedly the time difference is a challenge, but working hours can be made flexible in the case where engineers need to work with people on a different continent -- so it's less of a problem than you would expect.

    I stand by what I said: the issue is not with "offshoring", the problem is with mismanagement of third party resources.

  • John (unregistered) in reply to QJo
    QJo:
    What we did was opened our own office offshore, recruited and trained our personnel ourselves, and built up close personal relationships with our offshore staff. Those staff travel here on occasion "for the experience" mainly, and for particularly challenging projects that require extra physical proximity for managemental purposes.

    In turn, the project office in the American continent use the staff in this office (European based) as resource on their own projects as needed. It all depends on what particular skill mix is needed.

    Admittedly the time difference is a challenge, but working hours can be made flexible in the case where engineers need to work with people on a different continent -- so it's less of a problem than you would expect.

    I stand by what I said: the issue is not with "offshoring", the problem is with mismanagement of third party resources.

    That's not what most people consider to be offshoring.

  • agbeladem (unregistered)

    Stop showing off, start shoring off.

  • QJo (unregistered) in reply to John
    John:
    QJo:
    What we did was opened our own office offshore, recruited and trained our personnel ourselves, and built up close personal relationships with our offshore staff. Those staff travel here on occasion "for the experience" mainly, and for particularly challenging projects that require extra physical proximity for managemental purposes.

    In turn, the project office in the American continent use the staff in this office (European based) as resource on their own projects as needed. It all depends on what particular skill mix is needed.

    Admittedly the time difference is a challenge, but working hours can be made flexible in the case where engineers need to work with people on a different continent -- so it's less of a problem than you would expect.

    I stand by what I said: the issue is not with "offshoring", the problem is with mismanagement of third party resources.

    That's not what most people consider to be offshoring.

    So because in most people's experience, "offshoring" consists of a basically flawed business model, that means that all computer programmers beyond the borders of your own nation are "monkeys"?

    As I said: racism and xenophobia.

  • Watson (cs) in reply to QJo
    QJo:
    What we did was opened our own office offshore, recruited and trained our personnel ourselves.........

    I stand by what I said: the issue is not with "offshoring", the problem is with mismanagement of third party resources.

    But by your own declaration you're no longer dealing with third-party resources.

  • Watson (cs) in reply to QJo
    QJo:
    John:
    That's not what most people consider to be offshoring.

    So because in most people's experience, "offshoring" consists of a basically flawed business model, that means that all computer programmers beyond the borders of your own nation are "monkeys"?

    As I said: racism and xenophobia.

    "Offshoring" implies the assumption on the part of management that all programmers are fungible, so why not pay as little as possible for the cheapest programmers possible? Those companies that operate in territories where programmers are more expensive contract work out to programmers in territories where programmers are cheaper. One programmer is just as good as any other; and if the other programmer is only half as good that's fine if they cost less than half as much so you can afford to get two.

    As the Encyclopaedia Britannica describes the term:

    offshoring, the practice of outsourcing operations overseas, usually by companies from industrialized countries to less-developed countries, with the intention of reducing the cost of doing business. Chief among the specific reasons for locating operations outside a corporation’s home country are lower labour costs, more lenient environmental regulations, less stringent labour regulations, favourable tax conditions, and proximity to raw materials.

    If that's not what you're talking about, you're not talking about offshoring.

  • QJo (unregistered) in reply to Watson
    Comment held for moderation.

Leave a comment on “Offshore Obfuscation”

Log In or post as a guest

Replying to comment #:

« Return to Article