• (disco)

    While I understand that the "original submitter" and Front-Pageification Process might have left out details because of reasons, this story feels half-finished without any closing words from the boss.

    Has this Awesomeness reached the boss' ears? If not, Dave is TRWTF for continuing the myth that this DBA is legendary.

  • (disco)

    Oh, man, saw that one coming. :facepunch:

  • (disco)

    I'm here:

    His boss was resolute: “That. Is. Not. Your. Job. Don’t even worry about it. I’m sure Awesome knows how to do it.”

    Prediciton: DBA fucks up the code.

    Edit: Nope; got that call way wrong…

  • (disco) in reply to JBert

    Of course Awesome is on a salary about three times as big as Dave's and he will get a huge bonus for this job when Dave gets it working.

  • (disco) in reply to JBert
    JBert:
    If not, Dave is TRWTF for continuing the myth that this DBA is legendary.

    Being legendary is not the same as being good. Grendel, Loki and the Cyclops are all legendary. And I have come across DBAs that combined characteristics of some or all of them.

    Seriously, what kind of organisation is so clueless that there isn't a proper method of integrating the work of the DBAs and the application developers? This should be one of the primary jobs of technical management.

  • (disco) in reply to GettinSadda
    GettinSadda:
    Awesome is on a salary about three times as big as Dave's and he will get a huge bonus for this job when Dave gets it working.

    That's the ending we deserved, but not the one we needed. Or whatever.

    It's another case of incompetence being supported by management. Management support counts for way too much when it comes to technical solutions. Either that or I've had some REALLY bad examples of management competence.

  • (disco) in reply to kupfernigk
    kupfernigk:
    technical **management**
    I think we have our answer… :laughing:
  • (disco) in reply to Shoreline
    Shoreline:
    management competence

    There's your oxymoron problem, right there.

  • (disco)

    Dave is not Awesome's boss. Why is he evaluating his work? Why is he repairing his mess? If he makes a mistake merging records, it would be his fault.

    He didn't understand anything. This. Is. Not. His. Job. He is an application developer. He shouldn't be babysitting the Awesome.

    The right thing would be to say thanks for an optimization job and just wait. Make sure, every order has an written form. And Wait. For. The. Fun.

  • (disco) in reply to kupfernigk
    kupfernigk:
    Seriously, what kind of organisation is so clueless that there isn't a proper method of integrating the work of the DBAs and the application developers? This should be one of the primary jobs of technical management.

    *raises hand * /Regional government, 1600 employees.

  • (disco) in reply to martin
    martin:
    The right thing would be to say thanks for an optimization job and just wait. Make sure, every order has an written form. And Wait. For. The. Fun.

    Sometimes it can be helpful to (anonymously, within earshot of a journalist or activist) mention that you're having problems finding something on the site that used to be there and which is required to be there by law…

    I know exactly where the evil ideas thread is.

  • (disco)

    I call foul. Sorry, but these articles seem more and more like the local Agony Aunt - written by the editors themselves. I've been in many IT for 20-something years as a consultant and seen my fair share of idiots but really, a company with people as thick as this does not survive.

    Fairy tales.

    TDWFT used to be so good :(

  • (disco) in reply to Crispin
    Crispin:
    a company with people as thick as this does not survive.

    Who said that it was a company, or that it survived?

  • (disco)
    So Dave logged in, changed the configuration to point at the original location...
    No, no, no! Wrong approach entirely. The correct approach is to carefully refrain from strangling Awesome, then go to the boss and say, "Boss, we have a problem. All the records are gone from the database. Awesome deleted them to improve performance."

    Any approach that doesn't leave the boss up to his armpits in alligators along with everyone else will not teach the correct lesson.

    (Note: this is a theoretical approach, never tried in production. :innocent:)

  • (disco) in reply to RaceProUK
    RaceProUK:
    I think we have our answer

    NASA and the European Space Agency seem to be able to do technical management, so it obviously isn't rocket science. Oh...

  • (disco) in reply to kupfernigk
    kupfernigk:
    it obviously isn't rocket science

    https://www.youtube.com/watch?v=5pN2of8Ct-o&list=PL565C42B8343143BD&index=38

  • (disco)

    Ah, the incompetent DBA and the competent Developer who is not allowed to help. Even though in my experience it's usually the other way around (though I may be biased), I fondly remember the days before separation of duty and compliance requirements, when developers and DBA worked together on databases...now god forbid that any dev should ever see production data or any DBA wants to be more than "that guy who can install databases and execute tested schema upgrade scripts provided by development".

  • (disco)

    At least we have a nice tidy list of TRWTF:

    1. A DBA without programming knowledge;
    2. Said DBA having access to application code
    3. No back-ups. (Copy of live data on testing server doesn't count);
    4. No source control (Debugging to find code changes? No source control);
    5. "Awesome" idiots

    Have I missed any?

    .

  • (disco) in reply to ExaDBA
    ExaDBA:
    I fondly remember the days before separation of duty and compliance requirements, when developers and DBA worked *together* on databases
    Yeah, isn't that the way things are *supposed* to work to begin with? Sticking DBAs off in a total silo just generates fodder for this site...

    And compliance re: not torching or leaking (if applicable) the data is one thing -- but making it so that developers don't even have a sanitized or representative data set to develop with?! :wtf:

    Also, what in the name of all things holy is this notion of "separation of duties requirements"?

    ExaDBA:
    now god forbid that any dev should ever see production data
    While there are cases (PCI, HIPAA) where devs shouldn't see raw prod data, PCI compliance can be handled through a proper data sanitization process, for instance.

    Otherwise, why would you not give them read-only prod access?

    ExaDBA:
    any DBA wants to be more than "that guy who can install databases and execute tested schema upgrade scripts provided by development".
    The DBA job needs to be split in half in my mind:
    • On one hand, we have database operators, who are responsible for making sure that the databases and the hardware they run on don't fall on the floor (and fixing them when they do), making sure the data in them is backed up, applying patches, configuring instances, providing disk space, and pushing changes to prod (basically, the seemingly-modern definition of DBA)
    • On the other hand, we have database developers, who are responsible for query tuning, report development, and schema design -- these folks are free to work hand-in-hand with the dev team they're attached to.

    Also, which PHB came up with the notion that there shall only be one development environment/database per product?

  • (disco) in reply to tarunik

    We have database developers. It's a lot easier to get things done when you have a SQL developer writing the proc side of things and a web developer writing the API layer on top of it; the SQL guys know a lot more about database performance and tuning and query plans than any webdev wants to learn.

    We also have operational DBAs. They're mysterious and nobody talks to them because we have a huge ops/dev canyon.

  • (disco)

    TRWTF is Dave not having a backbone and/or better explaining the problem when his boss brought up the DBA as a solution.

  • (disco) in reply to Sylver
    Sylver:
    Have I missed any?

    Management who like to give people nicknames.

  • (disco) in reply to ExaDBA
    ExaDBA:
    now god forbid that any dev should ever see production data

    We all know that there is competence and incompetence on both sides. The sole justification for management is that it should lubricate the wheels, remove cinders from the track, and keep the trains running smoothly on the great railway of progress. Too often said management is too busy charging for tickets and trying to head off irate customers to, you know, actually keep the trains running. Box ticking leads to situations that would never be tolerated in any branch of engineering.

  • (disco) in reply to ExaDBA

    when developers and DBA worked together on databases

    Yeah, good luck finding an ITIL-locked silo-based organisation that will allow a developer anywhere near production environments. When any changes to QA and PROD means handing over complete deployment instructions to the ops-department through a change process, and you're not allowed to talk to the ops-people without a change system ticket and the DBAs classify as ops, developers just write their own damn sql. Based on the best guess as to what exists in production. It's blind luck that anything ever works in production.

    I favor a devops-process myself, with a dba, application ops and developer(s) on the same team, working closely together to make the solutions better. I luckily recently went from an ITIL based project to an established devops team. Best move I ever made.

  • (disco) in reply to tarunik
    tarunik:
    The DBA job needs to be split in half in my mind: * On one hand, we have database *operators*, who are responsible for making sure that the databases and the hardware they run on don't fall on the floor (and fixing them when they do), making sure the data in them is backed up, applying patches, configuring instances, providing disk space, and pushing changes to prod (basically, the seemingly-modern definition of DBA) * On the other hand, we have database *developers*, who are responsible for query tuning, report development, and schema design -- these folks are free to work hand-in-hand with the dev team they're attached to.
    Fortunately my company gets this pretty well right. (Though in my case I'm both the DB developer and app developer.) I'm responsible for the integration code that glues together our various systems. I'm also in charge of the schema for our BI warehouse. Add a bunch of columns? No problem. Slow query? I'll diagnose it, and if we need an extra index I'll add it; if we need some optimiser hints added to the query to change the execution plan, I'll add those. But if it's a problem with the database itself - redo logs are stuck, disk space is running low, whatever - then I pass it on to the DBA.

    We had a fun one a while back - the app server was running out of space repeatedly during the nightly BI run - turned out SQL tracing had been switched on for one of the applications running on it earlier in the day to resolve some issue, and they'd forgotten to turn it off, so when the nightly job started it was spewing out SQL data logs at a high rate until the disk filled up and everything stopped working. Cue some frantic text messages to the DBA in the middle of the night along the lines of "please switch this off immediately!"

  • (disco) in reply to PC_LoadLetter

    No good; if the relationship between the boss and "Awesome" is such that the former gave the latter that nickname, then it's probably the sort of relationship that the boss will decide is stronger than Dave's relationship with the "team".

  • (disco) in reply to Watson

    Exactly. Chances are the boss is too blinded by "Awesome" to do anything. Look at any of the myriad of similar topics, the clueless idiot is always the "golden boy" of the organization, so nothing is going to get them removed or put in their place, and anyone who tries will be themselves fired for stirring the pot.

    The whole "Its. Not. Your. Job" kind of crap just proves this is exactly that type of situation.

  • (disco) in reply to welcor
    welcor:
    It's blind luck that anything ever works in production.
    One of my great experiences with this was when we had trouble getting the timestamps right on a report generated from an Oracle database. I had been digging deep in all the different options Oracle offers (LOCALTIMESTAMP, TIMESTAMP WITH TIMEZONE, etc), and found some odd combination that worked between Oracle, C# and Java in test and prodution. Later it turned out that Oracle on the test and production server had different local settings. One had the appropriate national settings, the other was US. That *#($*&#$ piece of DBA was about as clueless as they come. Still, he was the one in charge of production, and indeed had a higher salary then the rest of us.

    I personally blame this development on "certification". Managers are deeply impressed by someone who can show a Microsoft Excel certificate (*) or an Oracle DBA certificate. But that's all these people know. They know how to type "ALTER TABLE...", without an effing idea about how that fits in with the rest of the software. But managers don't care about that. Look! He has a certificate! Let's not upset the DBA. Problem solved.

    (*) Microsoft Office Specialist: can open a 2nd spreadsheet without restarting the computer; Expert: can copy data between the two files; Master: knows how to add numbers in a column.

  • (disco) in reply to Hanzo
    Hanzo:
    I personally blame this development on "certification". Managers are deeply impressed by someone who can show a Microsoft Excel certificate (*) or an Oracle DBA certificate. But that's all these people know. They know how to type "ALTER TABLE...", without an effing idea about how that fits in with the rest of the software. But managers don't care about that. Look! He has a certificate! Let's not upset the DBA. Problem solved.

    Knowledge and learning are for people without product certification.

  • (disco) in reply to dkf
    dkf:
    Knowledge and learning are for people without product certification

    I think it is more like this: some people have natural curiosity and can find things out for themselves. Going to a university can facilitate and develop this. As my crystallography supervisor said to us, "You may never use crystallography after you leave but you will have learnt a way of classifying something complex." Going to a trade school (which is what certifications are) will give exact knowledge to someone who has curiosity and so can build on it. But unfortunately it will also certify the person who simply wants a job paying $x per hour and doesn't want to learn anything beyond it.

    It's not the certification so much as the people who just want to pass the test, and the people who want to collect their fees for doing the minimum tuition necessary.

  • (disco) in reply to kupfernigk

    You wrote three paragraphs to say part of what I managed in one short sentence. :stuck_out_tongue:

  • (disco)

    If this was about financial data instead, then I'd guess the company was MYOB Australia... Their fix for every slowness problem was always to simply hose your older data. If your data only went back 6 months, just burn your last quarter. It's not like you'd need that for taxes or customer returns or anything, right?

    And now that they do "cloud" versions, I can just imagine them ditching customer's records just because it got slow.

  • (disco) in reply to dkf
    dkf:
    You wrote three paragraphs to say part of what I managed in one short sentence

    And this is why programmers should never be allowed to write the user manuals.

  • (disco) in reply to kupfernigk
    kupfernigk:
    And this is why programmers should never be allowed to write the user manuals.

    I can blather when necessary. I save it for manuals, journal papers and books.

  • (disco) in reply to martin
    martin:
    He didn't understand anything. This. Is. Not. His. Job. He is an application developer. He shouldn't be babysitting the Awesome.

    Besides, by not doing anything about it himself, the blame will inevitably flow to Awesome when people discover the missing records.

  • (disco) in reply to dkf
    dkf:
    I can blather when necessary. I save it for manuals, journal papers and books.

    I can only bow in awe before your omnicompetence, modesty, and willingness to communicate with us helots.

  • (disco) in reply to FrostCat
    FrostCat:
    Besides, by not doing anything about it himself, the blame will inevitably flow to Awesome when people discover the missing records.

    You think Awesome won't claim that someone else deleted those records, along with a forged log if needed?

  • (disco) in reply to flabdablet
    flabdablet:
    kupfernigk:
    it obviously isn't rocket science
    [video snipped]
    http://www.youtube.com/watch?v=THNPmhBl-8I
  • (disco) in reply to urkerab

    [image]

    Hint: don't click anything until the screen above appears, or you'll be bounced out of the game.

Leave a comment on “The Awesome Optimization”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article