• Crank (unregistered) in reply to brian j. parker
    brian j. parker:
    Crank:
    SNF:
    Man, I was *so* sure that I was going to be the only person anal enough to notice and comment on that. And there it is in the first freaking comment. Hat's off, sir.

    It's amazing how many people assume they are smarter than everyone else (or at least think they're the only ones that ever notice anything....)

    I don't think he believes that as much as he believes he's the only one who would care enough to mention such a little nitpick...

    There's a difference between being smarter and being more pedantic. Only those who are the latter don't know the difference. :)

    But if he's thinks he's the only one who is pedantic enough to notice then clearly the pedants (or at least that pedant) know the difference ;)

    Oh...unless you were having a go at me....

  • cranky coder (unregistered) in reply to EmperorOfCanada
    EmperorOfCanada:
    Why is it that so many IT companies have small "elite" groups of people who firmly stand, and continue to stand, in the way of production?

    I think it ultimately comes down to laziness, power, and ego.

    For instance: some IT group controls servers that you use for development. So, any changes have to go through them. This is power.

    Now you need something done on the server to support your project (which is actually going to make the company money, unlike them). But, they can't be bothered to understand the needs of your project, so you have to spell out exactly what you need done, and basically tell them how to do their job. This is laziness.

    Then, if you suggest an improvement to this process, which will make life easier in general for both parties, they act offended and talk to you like you're a moron because you dared to question the Process. This is ego.

    (The above is based on a true story.)

    Sadly, it happens all the time. Someone insists things be done their way, even if it won't work, just because they're in charge: ego and power. Project manager doesn't invite you to relevant meetings: power and laziness. Someone refuses to accept a different approach to a problem because they'll have to change the way they do things: laziness and ego.

    Now you might think stupidity should be in there, and while it's high on the list, I don't think it's nearly as damaging (with exceptions) as the other three. In my experience, stupid people will at least get out of your way (until they get infected with either ego or power).

    It's not just in IT, mind you; this is a human failing, made worse by organizations.

  • (cs) in reply to JdFalcon04
    JdFalcon04:
    Jeff:
    CALL Query1('SPTST0001', '(DELETE FROM x,y,z)');

    Gotta love good security.

    I'm fairly certain that 'SELECT * FROM (DELETE FROM x,y,z')' would return a syntax error

    I think you're right. It would need to be something like this:

    CALL Query1('SPTST0001', 
'(SELECT * FROM USERS WHERE 1=0); DROP DATABASE EVERYTHING;');

    That semicolon should make all the difference.

  • Mr.'; Drop Database -- (unregistered)

    What database is this? Most databases treat SELECT * FROM (SELECT * FROM Table) as an error. You need to write SELECT * FROM (SELECT * FROM Table) please instead.

  • Alex (unregistered) in reply to Carl
    Carl:
    David:
    Corporate culture, good or bad, is very hard to change with anything short of bankruptcy
    And that's exactly why no organization, ever, should be allowed to grow "too big to fail". Guaranteed planetary-sized WTFfery surely follows.

    -- third try --

    Good observation dude.

  • LVBarnes (unregistered)

    I saw a few syntax error references above...but wouldn't the single quotes cause an error? The '(Select... would close on ...e=' and then cause an error right?

    CALL Query3('SPTST0001', '(SELECT a,b,c FROM x,y,z WHERE d=1 AND e='test' ORDER BY z.c)');

    LVBarnes

  • Anyone (unregistered) in reply to RBoy

    please explain this CAPTCHA stuff, it sounds like a new fad I haven't yet caught on to...

  • Anyone (unregistered) in reply to RBoy

    wtf? what do you mean "Capthca = Cogo.. Torgo's cousin."

  • Anonymous Coward (unregistered) in reply to SR
    SR:
    John:
    I'm fairly certain that 'SELECT * FROM (DELETE FROM x,y,z')' would return a syntax error

    Not an expert, but wouldn't:

    ('SELECT * FROM table1;DELETE FROM x,y,z')

    work?

    Not in a stored procedure.

    But it would work here. The stored procedure 'Query1' just executes some dynamic SQL (whatever is passed to it), thus the need to wrap the 'query' in parentheses.

  • Nobody (unregistered)

    Hope this query will fire the DBA:

    CALL Query3('SPTST0001', 'x; DROP TABLE RawQuery; --');

  • swordfishBob (unregistered) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    What database is this? Most databases treat SELECT * FROM (SELECT * FROM Table) as an error. You need to write SELECT * FROM (SELECT * FROM Table) please instead.
    You stuffed that up. "an error" becomes two tokens and won't be understood by the SQL parser. Try SELECT * FROM (SELECT * FROM Table) AS Buncha_Errors
  • Lee K-T (unregistered) in reply to Josh
    Josh:
    Drifting further off topic, this is also why IT costs so much. A dev (perhaps over-ambitiously) quotes a job at 5 days (although in my experience, this usually means that they think they'll do it in 2 days, but are arrogant enough to think that others would take 5, so they can have 3 days of reading TDWTF). The immediate Team Lead barely understands the problem (and certainly not the proposed solution) and quotes 10 days to his Manager (just to be sure), and adds 5 days testing, for a total of 15 days. The Project Manager (who is even further detached, and doesn't want to look bad if things go awry) doubles this quote to 30 days (and probably adds some caveat to allow him an excuse to fail - within 30%, say). The Program Manager (who has some limited knowledge of the budget available), and doesn't understand at all that only one line of code needs changing quotes for 50days (10 weeks is a nice round number). The Director needs to pass this on to the business/client and (just to make sure that all contingencies are covered) decides to go for 4 months, and rounds this off to 80 days. He then realises the budget should stretch fo rmore, and decides on 100 days (and reduces the escape clause to 15% - 30% sounds like our devs are incompetent). So far, we have a piece of work (which the original dev thought would take 2 days) which (including testing) has been quoted at 100 days. Keeping in mind that (for support work, at least) the bulk of the work is actually in the quote - you have to work out roughly what the problem is and how you will fix it before quoting), so the code is probably finished it just needs to be inserted, commented and refined slightly, we basically have very little to do and 100 days to do it in. So why do IT Projects frequently run over time/budget? The original developer leaves sometime between quoting and and the quote finally being submitted to business (and in leaving, never bothers to submit his code changes to version control - it's not approved work, after all). The new developer is one of two types. Type A realises that this quote is way OTT, and spends 8- days on facebook, before even looking at the problem. He discovers it's a little more complex than he expected, and wastes about 4 days working out the background and exactly what needs to be done (he is probably unfamiliar with the application at this stage). He spends a further 3 days making the change. Type B is a recent grad, who think he knows everything, but given that there are 100 Days to do this change, it must be more complicated than it appears on face value (and since management is obviously expecting a complicated solution, we may need to overcomplicate the problem if we can only think of a simple solution). Then redtape and politics delay the projects movement through the testing environments (meanwhile, everyone is charging to this project, even if there isn't actually any work going on), and we finally get to the testers on day 95. The testers (though originally allocated 5 days) are in a panic, because a 100 day project is only with them for 5 days (or 1/20th of the time for dev). Problems may or may not be found, but we can guarantee that this release will not make it into production on time....

    All time sheets show that this project took over the 100 days planned, yet very little work has actually happened. The problem is that the managers (who didn't understand what was going on) kept adding time, and the devs decided if they had the time allocated they'll use it. A good manager would (hopefully) present the dev's with a timeline (based on this over-quote) that was much tighter - 20 days, say, and then allow the project to slip if required. The devs never need to know anything more than their team leads quote for time.

    I digress, maybe I've worked in the public service too long sigh

    Well my experience is more like the exact opposit:

    • Sales guys find a customer.
    • Dev guys say it will take two month.
    • Sales guys sell for two weeks and explain that they know they know but the customer would have not signed for two month.
    • Dev guys build crap in two weeks to avoid the company being sued by customer.
    • Customer not happy because his soft sucks
    • Dev guys spend six month fixing a WTFish buggy soft that would have been perfect if only they have had two month in the beginning. And all this for a two weeks contract.
    • Sales guys don't give a s.... because they get 10% on the sales, not on what happens after.
    • Managers tells the dev team that he's happy it wasn't a two month project because if a two weeks project takes six month to debug, a two month project would have taken two years...
    • Dev guys leave the company
    • New dev guys come in, look at the code and post in TDWTF.
  • Anonymous (unregistered) in reply to Lee K-T
    Lee K-T:
    Josh:
    Drifting further off topic, this is also why IT costs so much. A dev (perhaps over-ambitiously) quotes a job at 5 days (although in my experience, this usually means that they think they'll do it in 2 days, but are arrogant enough to think that others would take 5, so they can have 3 days of reading TDWTF). The immediate Team Lead barely understands the problem (and certainly not the proposed solution) and quotes 10 days to his Manager (just to be sure), and adds 5 days testing, for a total of 15 days. The Project Manager (who is even further detached, and doesn't want to look bad if things go awry) doubles this quote to 30 days (and probably adds some caveat to allow him an excuse to fail - within 30%, say). The Program Manager (who has some limited knowledge of the budget available), and doesn't understand at all that only one line of code needs changing quotes for 50days (10 weeks is a nice round number). The Director needs to pass this on to the business/client and (just to make sure that all contingencies are covered) decides to go for 4 months, and rounds this off to 80 days. He then realises the budget should stretch fo rmore, and decides on 100 days (and reduces the escape clause to 15% - 30% sounds like our devs are incompetent). <snip>

    Well my experience is more like the exact opposit:

    • Sales guys find a customer.
    • Dev guys say it will take two month.
    • Sales guys sell for two weeks and explain that they know they know but the customer would have not signed for two month.
    • Dev guys build crap in two weeks to avoid the company being sued by customer.
    • Customer not happy because his soft sucks
    • Dev guys spend six month fixing a WTFish buggy soft that would have been perfect if only they have had two month in the beginning. And all this for a two weeks contract.
    • Sales guys don't give a s.... because they get 10% on the sales, not on what happens after.
    • Managers tells the dev team that he's happy it wasn't a two month project because if a two weeks project takes six month to debug, a two month project would have taken two years...
    • Dev guys leave the company
    • New dev guys come in, look at the code and post in TDWTF.
    I find it's a mixture of both. I'll quote five days for a two day job, with the intention of doing two days worth of work then reading TDWTF for the other three. Then my manager says "can you do it in four?" and I'll say sure, why not, that still gives me two days to read TDWTF. Then the sales manager will get on to my manager to tell him that we promised the functionality in one week. So then my manager sheepishly gets back to me to ask "actually, is there any way you can do it in three days so we've still got two days to cover test and deployment?". And I'll say sure, why not, that still gives me one day to read TDWTF. So now I've got three days to do a two day job. I've got plenty of time so the job gets done to a high standard and I've still got a free day to read TDWTF. But all of a sudden I'm a hero because I've turned the functionality round in half the time I originally quoted. The moral of this story is always estimate at least twice the amount of time its going to take you. More if you can get away with it.
  • JayDee (unregistered) in reply to Bob
    Bob:
    Swa:
    Ugh! At least at my current job we're doing our absolute best to remove all the crap from our SaaS app (the basic app was written by external consultants who were pretty much unconcerned with maintainability of the system, so we've got our share of WTF worthy stuff).

    How dare you accuse your consultants of being "unconcerned"! They were very concerned about the maintainability of the system. They wanted to be paid to maintain it and, to improve the odds, they tried to make sure that no one else could. Characterising that as "unconcerned" is just...well...WTF?

    He'll never make it as a consultant.

  • Elvis (unregistered)

    How does this "solution" make maintenance easier? Have they never heard of ALTER PROC? This really just blows my mind that a DBA (who should know better) would come up with such a clumsy ham fisted crap storm. I mean I can understand wanting all SQL queries run against the database to be in stored procs with parameters, but this?????? It is truly mind boggling.

  • Elvis (unregistered)

    How does this "solution" make maintenance easier? Have they never heard of ALTER PROC? This really just blows my mind that a DBA (who should know better) would come up with such a clumsy ham fisted crap storm. I mean I can understand wanting all SQL queries run against the database to be in stored procs with parameters, but this?????? It is truly mind boggling.

  • Elvis (unregistered)

    How does this "solution" make maintenance easier? Have they never heard of ALTER PROC? This really just blows my mind that a DBA (who should know better) would come up with such a clumsy ham fisted crap storm. I mean I can understand wanting all SQL queries run against the database to be in stored procs with parameters, but this?????? It is truly mind boggling.

  • Elvis (unregistered)

    How does this "solution" make maintenance easier? Have they never heard of ALTER PROC? This really just blows my mind that a DBA (who should know better) would come up with such a clumsy ham fisted crap storm. I mean I can understand wanting all SQL queries run against the database to be in stored procs with parameters, but this?????? It is truly mind boggling.

  • Mischief (unregistered) in reply to David
    David:
    I've not seen that before, but there are similar goings on in lots of companies. Someone comes up with some procedure to deal with a real or perceived problem. It's daft, but the person who came up with it doesn't want to admit to that, and/or the staff don't want to tell their manager he's wrong.

    So eventually people find a work-round, and everyone is happy. The developers can do their job, while having a laugh about the stupidity, and the manager doesn't feel challenged as the procedure is still in place.

    Occasionally a new manager will come in, discover the WTF, and suggest removing it. But by then everyone is used to the status quo, and quotes the cost of replacing a big legacy system, and some new issue comes up to take the new manager's time, so the WTF stays in place until long after anybody can remember the original reason.

    Corporate culture, good or bad, is very hard to change with anything short of bankruptcy, or mass redundancy in the department concerned.

    Yep. I deal with that everyday. I wish I had a nickle for every time I head "It's probably there for a reason."

  • anon (unregistered) in reply to Borg-nine
    Borg-nine:
    We have that problem here at Microsoft. It's called the Windows Division :-)
    Do you mean re-inventing the wheel?
  • methinks (unregistered) in reply to Capt. Obvious
    Capt. Obvious:
    Actually, the wheel has been through many revisions. It went to a perfect circle made out of wood, to having a rubber exterior, to having pneumatic cushioning, to mag wheels (which lower the weight of the wheel), to spinning rims.

    Okay, the last may be a counter-example, but wheel technology has upgraded over time.

    So have arrays, with actually checking the bounds instead of reading random memory.

    "Reinventing the wheel" is only bad if it isn't necessary. But to get to mag wheels, you had to go back and complety redo the construction a wheel from based on wood, spokes and hoop to a metal disk.

    Sorry, but no.

    "Reinventing the wheel" does not mean to change its design, form or material - it talks about the concept, which is undeniably the same for all your (and all other) examples of wheels.

    CAPTCHA: inhibeo = (lat.) I hold in, I check ;o)

  • phoenix (unregistered) in reply to Elvis
    Elvis:
    How does this "solution" make maintenance easier? Have they never heard of ALTER PROC? This really just blows my mind that a DBA (who should know better) would come up with such a clumsy ham fisted crap storm.
    Firstly, I would guess that the DBA isn't actually a DBA - possibly a sysadmin that's trying to fulfil the DBA role - but they're called (and regarded as) the DBA in that organisation. Secondly, DBAs don't usually write stored procedures - they're normally the domain of PL/SQL developers - so it's not unusual (in the Oracle world, anyway - don't know about MS-SQL et al) to find a DBA that has no knowledge of stored procedures.

    Not defending their practise, you understand. For supposedly skilled people to continue following a flawed policy and resist efforts to highlight its shortcomings is a pretty commonplace WTF. Sadly.

  • Outtascope (unregistered) in reply to Anonymous Coward

    Sorry, this one lacks the whiff of credibility. Is %#% a parameterized query format for some database I am unfamiliar with or is the story that the DBA does a string replace in the "stored" queries?

    While I am frequently astounded that the depths of human stupidity actually extend many fathoms further then I tend to give credit for (occasionally including my own lake of vacuousness), but I find it hard to believe that a DBA would go to these depths to control the SQL run on their database yet would be unfamiliar with prepared statements/parametrized queries (but not so with stored procedures).

    No database that I know of will allow you to use a bind parameter for a source/target (table name, column name, etc). So if this hack worked for SPTST0001, it would also work for every other query in the database by inclusion of an extra quote and/or semicolon, because the whole system was just string catting.

    I'm dubious.

    captcha eros: Sexy typos.

  • (cs)
    All time sheets show that this project took over the 100 days planned, yet very little work has actually happened. The problem is that the managers (who didn't understand what was going on) kept adding time, and the devs decided if they had the time allocated they'll use it.
    "Inwardly: alone. Here. Living under the land, under the sea, in the belly of AM, whom we created because our time was badly spent and we must have known unconsciously that he could do it better."
  • Goo (unregistered) in reply to Outtascope
    Outtascope:
    Sorry, this one lacks the whiff of credibility. Is %#% a parameterized query format for some database I am unfamiliar with or is the story that the DBA does a string replace in the "stored" queries?

    While I am frequently astounded that the depths of human stupidity actually extend many fathoms further then I tend to give credit for (occasionally including my own lake of vacuousness), but I find it hard to believe that a DBA would go to these depths to control the SQL run on their database yet would be unfamiliar with prepared statements/parametrized queries (but not so with stored procedures).

    No database that I know of will allow you to use a bind parameter for a source/target (table name, column name, etc). So if this hack worked for SPTST0001, it would also work for every other query in the database by inclusion of an extra quote and/or semicolon, because the whole system was just string catting.

    I'm dubious.

    captcha eros: Sexy typos.

    Maybe he was doing some catting because he wanted the statements to be recompiled every time? For example, in Postgres, if all you do is make a stored procedure that runs a query after passing some bound variables, the query is only planned once. While this is a good thing sometimes, other times it's rather suboptimal, because the planner had no idea of what the bound values were: It'd run the same plan whether the query was supposed to retrieve ten rows or ten thousand. plain catting is awful, but it does get around such problems.

  • Anon (unregistered) in reply to Outtascope

    It would depend on the database, some databases don't support binding parameterized queries and would treat % as a string replacement like a %s in C, for instance the versions of Informix DBMS that I have used would allow this if the parameter was a varchar or text types.

  • Sylver (unregistered) in reply to VRAndy
    VRAndy:
    Capt. Obvious:
    Actually, the wheel has been through many revisions. It went to a perfect circle made out of wood, to having a rubber exterior, to having pneumatic cushioning, to mag wheels (which lower the weight of the wheel), to spinning rims.
    Perhaps you've missed the, er..., obvious, difference between "refining" and "reinventing"?
    Actually, if you were to look up the word "reinvent" in a dictionary, you might find that it means "create new version of something: to change radically the appearance, form, or presentation of something or somebody" (Encarta), which is an apt description of the changes in wheel designs.
  • Lee K-T (unregistered) in reply to phoenix
    phoenix:
    Secondly, DBAs don't usually write stored procedures - they're normally the domain of PL/SQL developers - so it's not unusual (in the Oracle world, anyway - don't know about MS-SQL et al) to find a DBA that has no knowledge of stored procedures.

    Ok so the projects you've worked on had clients developers, servers developers, DBAs, PL/SQL developers, Sysadmns... etc... You might be surprised but sometimes project just don't have 500 persons involved in but 2-3 or even less. And some software guys are given more scope than just "you take care of this bolt, the rest is not your problem"

  • Anyone (unregistered)

    CAPTCHA: Your Mum (I think I got the hang of this now).

  • PRMan (unregistered) in reply to Anonymous

    "When developers have to take advantage of security flaws in order to do what they need to do to get the job done, it's time review your architecture. And fire somebody."

    This.

  • badger (unregistered) in reply to Josh

    This is only true of people who are only reasonably competent. The genuine elite - the super-capable engineers, do not need to horde or to announce themselves as elite. The telltale sign for a problem child? Someone who talks about being the best. Truly gifted engineers don't need to say anything: They're busy building great things. Most I've met are good natured and generous.

  • Cantalopian (unregistered) in reply to Anonymous

    This is revealed truth. I learned 'take your best estimate and multiply by pi'.

    Sometimes developers (like me) are tempted to come up with insanely tight time lines, perhaps in an effort to look talented and dedicated. Never do this! Always leave yourself time to recover!

    When you beat your estimate, a little squirt of dopamine is released in the customers brain.

    when you fall behind, he will eat crabby patties.

    -Cantalopian

  • Giammarco (unregistered)

    Fantastic!! :-)

  • al (unregistered) in reply to tim

    That is hysterical!

    PS - Now I understand why there are people out there that hate stored procs.

  • Gary Parkin (unregistered)

    Amazing. I love it. Thank you.

  • anonymous (unregistered)

    When I saw SELECT * FROM %1% I was actually expecting to see code load entire tables into arrays and do all of the filtering and sorting in VB...

Leave a comment on “For the Ease of Maintenance”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article