• Kent (unregistered)
    told the users that they simply had to keep manually enter their changes in both Purchize and Oracle.
    No biggie, give me a few hours and I can cobble up a new database for the original entry, which will feed both Purchize and Oracle.

    Solved!!

    ?

  • (cs) in reply to Remy Porter
    Remy Porter:
    I actually added fonud to my spellchecker, just to toy with you all.

    so are you going to award a prize the next time that this word is fonud in an article, and the commenter references this article?

  • DMJ (unregistered)

    Somehow I missed the part where he put his resume out because this job was ... well, less than desirable.

  • Frank Lee (unregistered)

    Then the auditor walked into the room, took one glance at the whiteboard, and had a heart attack then and there.

    They rushed him to the hospital where, unfortunately, the president's daughter and the grad student were being treated for a highly virulent condition.

    When the auditor realized he was going to die, he called the VP of Global Purchasing, not wanting the monstrosity he had found to live on in his absence. (That's the whiteboard monstrosity, not the president's monstrosity, in case you're wondering.)

    Unfortunately the highly virulent condition was the first virus that has both physical and electronic components, so it spread over the phone line and killed the VP of Global Purchasing.

    I love a happy ending!

  • (cs) in reply to Dave
    Dave:
    The whole time I was expecting the article to end with some moral about not having P.E.E. (Purchasing Enterprise Examiner) in your pool (of data solutions).

    Just occurred to me that yesterday's auditor ought to have asked questions about memory leaks ...

  • Chuck Finley (unregistered) in reply to Raedwald
    Raedwald:
    Integration in the database layer often means trying to reconcile keys with no natural relationship

    Sounds better if you imagine this being spoken like a voice over from Burn Notice.

    I agree!

  • Some Damn Yank (unregistered) in reply to Pock Suppet
    Pock Suppet:
    Then it's time for a meeting where IT gets called on the carpet to explain why we "broke" things.
    I worked on a project once involving migration to newer workstations/OS versions. The team for one in-house program said they could not guarantee it would give accurate results on the new platforms, only that it would give the same results as it gave on the old platforms. I found that position refreshingly honest and pre-emptively butt-covering.
  • Some Damn Yank (unregistered) in reply to iMortalitySX
    iMortalitySX:
    I think there is always a WTF if you draw a chicken and call it a data flow. Seriously though, am I the only one that sees a chicken in the drawing?
    Yes, you are.
  • wldkrd1 (unregistered) in reply to Chuck Finley
    Raedwald:
    Integration in the database layer often means trying to reconcile keys with no natural relationship

    Sounds better if you imagine this being spoken like a voice over from Burn Notice.

    I prefer a voice over from March of the Penguins

  • Mitch (unregistered) in reply to chubertdev
    chubertdev:
    Remy, time to update your schedule:
    1. caffeine
    2. author article
    3. more caffeine
    4. proofread article
    5. toilet break
    6. profit
    FTFY
  • Jazz (unregistered)

    TRWTF is that managers / executives still think allowing mission-critical systems to be built with this kind of a design is a good idea.

    Okay, but seriously. Take your average VP at a company that has a long supply chain managed with some enterprise software. Somewhere between birth and becoming employed as an executive, one presumes that the VP underwent a process of education, in which they transitioned from a state of not-knowing-how-to-manage to a state of knowing-how-to-manage. Right? This can be reasonably inferred from the fact that the VP was judged to be qualified for their job when they were hired. And part of that educational process involves becoming familiar with documented cases of poor management choices in the past, so that (ostensibly) the VP can avoid the mistakes that other executives have made. Right? And there are numerous documented cases of management choosing a system with a half-assed architecture like this because it's cheaper, and then later coming to regret it, over the past 15-20 years. Right? And, given that this education is in the field of management theory & practice, rather than in the field of software engineering, the many reasons to avoid this architecture are expressed (and learned) in business terminology (i.e. "negatively impacts revenue streams") that the students can understand, rather than in technical terminology (i.e. "fails validation and rolls back") that they might not.

    Therefore, anyone who is judged to be qualified for an executive position in today's market has already been educated on the dangers that this kind of system architecture poses for the company's bottom line and long-term health, and knows to avoid it.

    Therefore, any executive who continues to advocate in favor of such a system is knowingly risking the long-term prospects of the company, and therefore is poorly-qualified for their job. And this should be reflected on their reviews (and if it's not, their reviewer is poorly-qualified to be reviewing them).

    (Captcha: 'minim' -- the required amount of intelligence to land a $400k job.)

  • juan (unregistered) in reply to wldkrd1
    wldkrd1:
    Raedwald:
    Integration in the database layer often means trying to reconcile keys with no natural relationship

    Sounds better if you imagine this being spoken like a voice over from Burn Notice.

    I prefer a voice over from March of the Penguins

    Integration in the database layer often means trying to reconcile keys with no natural relationship....These are their stories.....

  • Z (unregistered) in reply to Michael
    Michael:
    This is simply the status-quo most places I have worked. I agree that it's broken and messed up, but hardly a WTF.

    TRWTF is the fact that you agree that it is broken and messed up, but don't see the WTF.

  • (cs) in reply to Mitch
    Mitch:
    FTFY

    Ahhh, you ruined it.

  • (cs) in reply to golddog
    golddog:
    I overheard our recently-hired DBA/Data Architect talking with someone, explaining how to generate a script out of a database on SQL Server.

    "When you save the script, make sure to save it as ANSI, not Unicode. When you save as Unicode and check it into a repository, that messes up the file."

    Please tell me you're not still using Source Safe.
  • (cs) in reply to Shoreline
    Shoreline:
    Pock Suppet:
    DogsBody:
    snoofle:
    Interestingly, our users only care about getting their reports. Yet they've never complained about all the broken data on which they're based.

    I've had users complain when data was fixed as it broke their workarounds!

    This. Give me the friggin report now! No need for accuracy! No one actually looks at those numbers in the first place! It's all about relative numbers! Just make the change I told you to!

    Right until we get a client who is able to count past 20 and notices the report stupidity. Then it's time for a meeting where IT gets called on the carpet to explain why we "broke" things. Usually accompanied by the words "It never used to work like that!" And everyone thinks I'm crazy for never deleting emails...

    Same. "How come you never delete emails?" "Leverage."

    People still delete emails? With inboxes in the tens of gigabytes these days, you'd have to be an awfully compulsive person to bother hitting delete instead of "read next".

  • (cs) in reply to Jazz
    Jazz:
    TRWTF is that managers / executives still think allowing mission-critical systems to be built with this kind of a design is a good idea.

    Okay, but seriously. Take your average VP at a company that has a long supply chain managed with some enterprise software. Somewhere between birth and becoming employed as an executive, one presumes that the VP underwent a process of education, in which they transitioned from a state of not-knowing-how-to-manage to a state of knowing-how-to-manage. Right? This can be reasonably inferred from the fact that the VP was judged to be qualified for their job when they were hired. And part of that educational process involves becoming familiar with documented cases of poor management choices in the past, so that (ostensibly) the VP can avoid the mistakes that other executives have made. Right? And there are numerous documented cases of management choosing a system with a half-assed architecture like this because it's cheaper, and then later coming to regret it, over the past 15-20 years. Right? And, given that this education is in the field of management theory & practice, rather than in the field of software engineering, the many reasons to avoid this architecture are expressed (and learned) in business terminology (i.e. "negatively impacts revenue streams") that the students can understand, rather than in technical terminology (i.e. "fails validation and rolls back") that they might not.

    Therefore, anyone who is judged to be qualified for an executive position in today's market has already been educated on the dangers that this kind of system architecture poses for the company's bottom line and long-term health, and knows to avoid it.

    Therefore, any executive who continues to advocate in favor of such a system is knowingly risking the long-term prospects of the company, and therefore is poorly-qualified for their job. And this should be reflected on their reviews (and if it's not, their reviewer is poorly-qualified to be reviewing them).

    (Captcha: 'minim' -- the required amount of intelligence to land a $400k job.)

    7/10 would flame if in bad mood (sorry, can't do "Not Bad" meme from work)

  • Your Name (unregistered) in reply to Jazz
    Jazz:
    Take your average VP at a company that has a long supply chain managed with some enterprise software. Somewhere between birth and becoming employed as an executive, one presumes that the VP underwent a process of education, in which they transitioned from a state of not-knowing-how-to-manage to a state of knowing-how-to-manage. Right? This can be reasonably inferred from the fact that the VP was judged to be qualified for their job when they were hired.

    I'm gonna stop you right there. Your average VP, particularly in a WTF-heavy company like the ones that show up here, was hired into the position because they know a guy who knows a guy who knows a guy, so to speak. Now, I'm not saying every VP is like that, but there's a large percentage of them that are, and they're more likely to end up on this site.

  • Nim (unregistered)

    I think I stumbled upon something similar in a D&D adventure some time ago. But there it was called the Demonweb Pits.

  • Simon (unregistered)

    Good call from the VP. Entering data into two systems in parallel might be annoying and error prone, but as an immediate fix, it's absolutely the right thing to do. At worst, it's less of a disaster than the current system, and doesn't have the risk of trying to make changes to the wider system while under time pressure.

    Clued-up management... who'd have thought it possible?

  • Harrow (unregistered) in reply to Kent
    Kent:
    told the users that they simply had to keep manually enter their changes in both Purchize and Oracle.
    No biggie, give me a few hours and I can cobble up a new database for the original entry, which will feed both Purchize and Oracle.
    Good idea.

    Microsoft Access is an excellent tool for this, but Tony already has an Access application or two in his snake pit. For extended job security I would have to suggest Borland Paradox for Windows v. 7/32, which seems to be the only remotely db-related tool they are not already using.

    -Harrow.

  • Barfo Rama (unregistered) in reply to Pock Suppet

    You get change requests by email?

  • (cs) in reply to Some Damn Yank
    Some Damn Yank:
    iMortalitySX:
    I think there is always a WTF if you draw a chicken and call it a data flow. Seriously though, am I the only one that sees a chicken in the drawing?
    Yes, you are.
    I see the chicken. I had to get really high first tho.
  • The Joker (unregistered)

    It's simple, we ummm...

    We kill the batman.

  • Paul (unregistered) in reply to Your Name
    Your Name:
    Your average VP, particularly in a WTF-heavy company like the ones that show up here, was hired into the position because they know a guy who knows a guy who knows a guy, so to speak.
    Let's just assume for discussion that this is true. The reasonable follow-up question is... Why?

    Take two companies in a similar line of business. One is run by a bunch of clueless pals. The other hires smart competent people. Wouldn't the good company kick the bad company's butt all over town?

    My theory: taxpayer funded bailouts to keep the stupid ones afloat?

  • The Crunger (unregistered) in reply to Jazz
    Jazz:
    TRWTF is that managers / executives still think allowing mission-critical systems to be built with this kind of a design is a good idea.
    Jazz:
    Therefore, anyone who is judged to be qualified for an executive position in today's market has already been educated on the dangers that this kind of system architecture poses
    Which manager actually praised the system design? Most of the time, even the dimmer ones realize that a monster is growing, while they themselves bolt on one irregular chunk at a time.

    It's not that the knowledge of how to achieve a database schema, fully compliant with 3NF hurts, but using that knowledge really doesn't help.

    Your job is to make your SBU succeed -- nothing else. When the business systems your SBU needs aren't in place, it's time to pick, purchase, staff, and integrate. The best choice for your SBU is to add your our particular streaming contribution to "the pool". You can advocate for the greater good after you've dodged the reaper.

  • urza9814 (unregistered) in reply to Paul
    Paul:
    Your Name:
    Your average VP, particularly in a WTF-heavy company like the ones that show up here, was hired into the position because they know a guy who knows a guy who knows a guy, so to speak.
    Let's just assume for discussion that this is true. The reasonable follow-up question is... Why?

    Take two companies in a similar line of business. One is run by a bunch of clueless pals. The other hires smart competent people. Wouldn't the good company kick the bad company's butt all over town?

    My theory: taxpayer funded bailouts to keep the stupid ones afloat?

    The less consumer-oriented a company is, the dumber it can be. If Amazon.com pulled this kinda crap, their service would start to suck and people would start switching to alternatives. Although they'd have enough momentum to survive quite some time...

    But this doesn't seem like the kind of company that deals directly with consumers. They get a few large contracts and they're good. And they get those contracts from the company owned by the CEO's golfing buddy...or, of course, from his uncle, Sam...

  • eVil (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    Some Damn Yank:
    iMortalitySX:
    I think there is always a WTF if you draw a chicken and call it a data flow. Seriously though, am I the only one that sees a chicken in the drawing?
    Yes, you are.
    I see the chicken. I had to get really high first tho.

    TRWTF is anyone who didn't see the chicken.

  • (cs)

    The Real WTF is how many managers/higher-ups actually think that yelling at people is a positive way to get anything accomplished. I thought we all learned in kindergarten (or maybe first grade) that screaming and throwing a tantrum isn't how you deal with people.

  • Mike (unregistered) in reply to Raedwald

    that is why it is essential to have covering fire. Preferably with heavy rifles and rocket launchers.

  • VJG (unregistered) in reply to iMortalitySX

    Yes, I see the chicken. I was going to announce it and thought I'd better see if anyone else had already pointed it out.

    Now I can't finish reading the article. I keep seeing that blasted chicken in my peripheral vision.

    It frightens me.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Dave:
    The whole time I was expecting the article to end with some moral about not having P.E.E. (Purchasing Enterprise Examiner) in your pool (of data solutions).

    Just occurred to me that yesterday's auditor ought to have asked questions about memory leaks ...

    Time to tell the VP "You're in over your head."

  • (cs) in reply to Soviut
    Soviut:
    People still delete emails? With inboxes in the tens of gigabytes these days, you'd have to be an awfully compulsive person to bother hitting delete instead of "read next".
    Only 200 MB allocation from Microsoft Exchange here.
  • justme (unregistered) in reply to golddog
    golddog:
    CleanCode:
    TRWTF is no mention of a database architect, or any technical people between a VP and the poor IT guy.

    Let's not suggest that is necessarily the solution.

    I overheard our recently-hired DBA/Data Architect talking with someone, explaining how to generate a script out of a database on SQL Server.

    "When you save the script, make sure to save it as ANSI, not Unicode. When you save as Unicode and check it into a repository, that messes up the file."

    I remain unimpressed.

    While I don't like the Captcha repeating meme, I find it sadly ironic that it's "genitus" for this post. Which might describe our DBA: not quite a genius.

    Actually, they are partly right , but probably did not explain it correctly. I have run into Unicode/ANSI issues when using VS and MSSM and the export feature.

  • justme (unregistered) in reply to DrPepper
    DrPepper:
    [So, all of these other systems stopped merely dumping data into the Examiner, and started extracting data too.]

    An ad-hoc reporting system morphs into a "source of truth". There should have been about a hundred DBAs who choked on that idea; [bold]their role is the protection of the integrity of their data at all costs. [/bold]

    Allowing data to flow back into one of their systems from an untrusted source should have raised red flags up the chain. And should have resulted in the firing of the people who allowed the data to get so screwed up.

    Okay, help needed. Not a formally trained DB but fell into it. I was arguing with someone the other day. Should users be allowed to delete records that they create ( that have not be used in any transaction ). I was told that it should stay, but we could transition it to the last state [final]. I objected because I saw this as 1) mucking up the state of "final". Final implies it has gone through all the states including released. 2) while general users would not be able to see he data, it would still be sitting there for the owner 3) it would skew metrics 4) why allow known junk to stay.

    Thoughts ?

  • justme (unregistered) in reply to Jazz
    Jazz:
    TRWTF is that managers / executives still think allowing mission-critical systems to be built with this kind of a design is a good idea.

    Okay, but seriously. Take your average VP at a company that has a long supply chain managed with some enterprise software. Somewhere between birth and becoming employed as an executive, one presumes that the VP underwent a process of education, in which they transitioned from a state of not-knowing-how-to-manage to a state of knowing-how-to-manage. Right? This can be reasonably inferred from the fact that the VP was judged to be qualified for their job when they were hired. And part of that educational process involves becoming familiar with documented cases of poor management choices in the past, so that (ostensibly) the VP can avoid the mistakes that other executives have made. Right? And there are numerous documented cases of management choosing a system with a half-assed architecture like this because it's cheaper, and then later coming to regret it, over the past 15-20 years. Right? And, given that this education is in the field of management theory & practice, rather than in the field of software engineering, the many reasons to avoid this architecture are expressed (and learned) in business terminology (i.e. "negatively impacts revenue streams") that the students can understand, rather than in technical terminology (i.e. "fails validation and rolls back") that they might not.

    Therefore, anyone who is judged to be qualified for an executive position in today's market has already been educated on the dangers that this kind of system architecture poses for the company's bottom line and long-term health, and knows to avoid it.

    Therefore, any executive who continues to advocate in favor of such a system is knowingly risking the long-term prospects of the company, and therefore is poorly-qualified for their job. And this should be reflected on their reviews (and if it's not, their reviewer is poorly-qualified to be reviewing them).

    (Captcha: 'minim' -- the required amount of intelligence to land a $400k job.)

    You are underestimating the effects of hubris on executive decision making. They have heard the stories, but believe they are immune.

  • observer (unregistered)

    Any company that implements a reporting ecosystem as haphazard as this deserves all the bad things it could get. The WTF is that the company did not sink.

  • (cs) in reply to justme

    [quote user="justme\Okay, help needed. Not a formally trained DB but fell into it. I was arguing with someone the other day. Should users be allowed to delete records that they create ( that have not be used in any transaction ). I was told that it should stay, but we could transition it to the last state [final]. I objected because I saw this as 1) mucking up the state of "final". Final implies it has gone through all the states including released. 2) while general users would not be able to see he data, it would still be sitting there for the owner 3) it would skew metrics 4) why allow known junk to stay.

    Thoughts ? [/quote]

    Two parts:

    1. Data should be validated and verified before hitting the "main system"...there should be NO junk...

    2. Once data exists it is part of an audit trail and must be subject to approved formal retention policies (many of which are legally mandated)..in general this means no deletion...using 'final' may be a WTF, and an appropriate solution might be moving to some other datastore...but having the data "simply be gone" (bfore expiration according to retention policy] is a major WTF.

    (note that if this was followed in the story, thre would have been no story....]

  • Rob (unregistered)

    Sounds to me like that corporation misses the concept of data ownership. Different corporate systems almost always end storing similar kinds of data (like product information) and also end up publishing data to other systems. There is nothing really wrong with this, but errors occur when a local system fail to identify who owns which records. The local system can delete those records that it owns and notify other systems that the local system has deleted that record. A local system can delete records that it does not own(remove them from its system) , but the local system can't delete records owned by another system and tell other systems to remove them as well.

    The same thing applies to updates. If a local system owns the record, then only it can change the record and publish the change, but when the local system does not own the record, it can only update the record within the scope of the local system.

  • nasch (unregistered) in reply to Jazz
    Jazz:
    TRWTF is that managers / executives still think allowing mission-critical systems to be built with this kind of a design is a good idea.

    I don't think "design" is really the right word here.

Leave a comment on “Purchasing Enterprise Examiner”

Log In or post as a guest

Replying to comment #:

« Return to Article