- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
What did I miss? It does use GETDATE(), although in a bizarro fashion. I'd question whether timezones were properly accounted for though.
Admin
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.
Admin
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)
Admin
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.
Admin
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...
Admin
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.
Admin
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
Admin
Point well missed. Good work!
Admin
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.
Admin
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
Admin
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.
Admin
I'd rather have the client send in the ID of the last message it succesfully processed.
Admin
Agreed
Admin
+ 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).
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
We're making it work.
Admin
Admin
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.
Admin
This is a highly dubious claim, to say the least. I've seen too many things like
to really take such statements without huge grains of salt.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
I thought the real WTF was that the code would end up with an inefficient plan (possibly scanning every row in the table) instead of using the work order date separately (which is most likely indexed).
set @yesterday = ...
... where wo.DTWCOMPL >= @yesterday
Admin
This is very, very high quality offshore code.
Admin
Admin
It's a relative term. The offshore code that I've worked with was a prime example of how to do everything wrong.
Admin
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
Admin
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.
Admin
Admin
Admin
You're a fake Nagesh, there is no grammar mistake in your sentence.
Admin
Yep it's true. I hate shitty code.
Admin
This, not
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!
Admin
Admin
So, out of curiosity, which was it: Just plain old idiot-broken? Or did they overload the && operator?
Admin
I think he's referring to this... http://thedailywtf.com/Articles/Chinese,-Korean-Japanese--Its-All-the-Same.aspx
Admin
fuck you mods deleting my post
Admin
Then don't make shitty posts?
Admin
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.
Admin
That's not what most people consider to be offshoring.
Admin
Stop showing off, start shoring off.
Admin
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.
Admin
But by your own declaration you're no longer dealing with third-party resources.
Admin
"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:
If that's not what you're talking about, you're not talking about offshoring.
Admin
Um, yes it is, actually -- read the definition you posted from E.B. and compare it to the slanted and biased definition which you actually wrote.
We're a company in "an industrialised country utilising resources from a less-industrialised country in order to reduce the cost of doing business." What is there about our operation as I have described it that does not coincide with the definition on Wikipedia? See? It doesn't even match what you've said!
It appears that your own undertstanding of "offshoring" is in fact what I would define as "outsourcing", which under my own understanding means "using a third party".
"Outsourcing" is a different business altogether, and needs its own management style.
I stand by what I said. We use the technique of offshoring. We just manage it well and are making a considerable success of it.
At times we also use "offshore outsourcing" as appropriate, but (without mentioning any names) fell foul of exactly the same company (some years ago now, we learned our lesson and never used them again) that has been in the news recently for fouling up a high-profile government contract (can't remember which now). On the other hand, we have used some which were pretty good, and the best ones we have acquired as partners or subsidiaries.
So: get your management structures sorted out and get with the program. Or go under: it's as simple as that.