• (cs)

    There was obviously one requirement missing from Terry's spec:

    • Make it not crap.

    Also, frist!

  • (cs) in reply to DaveK
    DaveK:
    There was obviously one requirement missing from Terry's spec:
    • Make it not crap.
    I'd have gone with the more explicit: Don't design this while on crack.
    DaveK:
    Also, frist!
    Why, you little...
  • (cs) in reply to DOA
    DOA:
    DaveK:
    There was obviously one requirement missing from Terry's spec:
    • Make it not crap.
    I'd have gone with the more explicit: Don't design this while on crack.
    Crack would have made it better.
    DOA:
    DaveK:
    Also, frist!
    Why, you little...
    ITYM "Why, I oughta ..."?
  • (cs)

    I was actually on tdwtf when he put the article up, and my first thought (very, very sadly) was to go type a comment that was simple "First!" Luckily, DaveK saved me from this humiliation by doing it instead.

  • (cs)

    It is 2009, and I'm working on a process that looks frighteningly similar to that flowchart.

  • (cs) in reply to DaveK
    DaveK:
    DOA:
    Why, you little...
    ITYM "Why, I oughta ..."?
    Think Homer Simpson
    Sutherlands:
    my first thought (very, very sadly) was to go type a comment that was simple "First!"
    Ah, the fresh snow syndrome... don't worry everyone suffers from it.
  • SomeCoder (unregistered)

    Looks like you forgot to add a "Yes" and a "No" on the last Yes/No gate in your flowchart.

    Also... as I read through the flowchart, this WTF actually made me say "What the fuck...?" out loud. This is... pretty terrible to say the least.

    I'd recommend goggles but they do nothing.

  • (cs) in reply to Sutherlands
    Sutherlands:
    I was actually on tdwtf when he put the article up, and my first thought (very, very sadly) was to go type a comment that was simple "First!" Luckily, DaveK saved me from this humiliation by doing it instead.
    Well, at least I made a comment on the story. The point was, obscurely put, that the requirement specs should include at least some idea of an architecture, or at the least should have an approval clause of the major design before the implementation goes ahead.

    [EDIT: Argh. I hit submit too soon, and now the delete function isn't working. Sorry for doubleposting.]

  • (cs) in reply to Sutherlands
    Sutherlands:
    I was actually on tdwtf when he put the article up, and my first thought (very, very sadly) was to go type a comment that was simple "First!" Luckily, DaveK saved me from this humiliation by doing it instead.
    Well, at least I made a comment on the story. The point was, obscurely put, that the requirement specs should include at least some idea of an architecture, or at the least should have an approval clause of the major design before the implementation goes ahead.

    So I'm afraid if you want a simple "First", you'll have to post it yourself after all.

  • Alex G. (unregistered)

    I read through the flowchart, and I have this sudden urge to donkey punch people in the kidneys.

    I would expect such a thing be a criminal offense on some level that would result in incarceration. For many years. With the whole soap in showers affair.

    Seriously, couldn't they sue them or ask for their money back, or at least a correct product?

  • James (unregistered)

    My worst fear is, how do you word a contract so you can avoid paying for the software if it's this terrible?

    It's like if you went to get a custom-tailored suit, and you get it home to find out most of the cloth is held together with staples and chewing gum.

  • RBoy (unregistered)

    What letters would you like in your comment?

    A[0] B[0] C[0] D[0] E[0] F[1] ....

    Your Comment contains:

    F[1] T [1]

    Is this correct?

    What letters would you like in your comment?

    A[0] B[0] C[0] D[0] E[0] F[1] ....

    Your Comment contains:

    F[1] T[1] W[1]

    Is this correct?

    Sending Order . . . . . . Order Complete

  • (cs) in reply to DOA
    DOA:
    DaveK:
    DOA:
    Why, you little...
    ITYM "Why, I oughta ..."?
    Think Homer Simpson
    Oh.... [image]
  • (cs) in reply to James
    James:
    My worst fear is, how do you word a contract so you can avoid paying for the software if it's this terrible?
    You add an approval clause, where they have to submit the design and architecture for your approval before moving on to the next stage of implementing that design. It's actually quite normal in a lot of development contracts.
  • (cs)

    Give me a few minutes while I copy the entire database of comments and set the quantity of the one I want to post to 1.

  • Roy T. (unregistered)

    I don't understand why they didn't ask for a refund. Doesnt refunds for crappy acomplishments exsists in America (assuming american companies since tdwtf is armerican).

    We always hear about those lawyers trying to sue everyone. Why not do that here? The program is definately flawwed. Or don't judges have the technical know-how to do justice in these matters?

    (Sorry for the mumbo-jumbo I'm not a native English speaker)

  • (cs)

    re: How do you word a contract to include "make it not crap"?

    It's called service level agreement; performance must meet certain minimum criteria (eg: order must be enterable from scratch in x seconds with at most n clicks for single item purchase, or back-end processing completes in x ms). This way, crap designs like this implicitly fail.

    Oh and BTW, putting 15000 items in an on-screen list? Priceless!

  • (cs) in reply to Roy T.
    Roy T.:
    I don't understand why they didn't ask for a refund. Doesnt refunds for crappy acomplishments exsists in America (assuming american companies since tdwtf is armerican).

    We always hear about those lawyers trying to sue everyone. Why not do that here? The program is definately flawwed. Or don't judges have the technical know-how to do justice in these matters?

    (Sorry for the mumbo-jumbo I'm not a native English speaker)

    Probably because they didn't want to throw good money after bad.

  • T604 (unregistered) in reply to James

    SLA

  • (cs)

    Um, I'm looking at this box:

    Copy the entire database of products to an Order database and an additional column 'quantity' is added (15,000 items total).

    I think that's supposed to be "... to an Order table", yes?

    So, either the site works properly only when one user is shopping, or every user gets their own personal table. Brillant.

  • Alin (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    Um, I'm looking at this box:
    Copy the entire database of products to an Order database and an additional column 'quantity' is added (15,000 items total).

    I think that's supposed to be "... to an Order table", yes?

    So, either the site works properly only when one user is shopping, or every user gets their own personal table. Brillant.

    No, they would just create a database of databases. Super Brillant!

  • (cs) in reply to SomeCoder
    SomeCoder:
    Also... as I read through the flowchart, this WTF actually made me say "What the fuck...?" out loud. This is... pretty terrible to say the least.

    That happened to me when I got to the lower left hand part of the flowchart. The part about deleting the item if quantity is not greater than 0.

  • (cs) in reply to Alin
    Alin:
    No, they would just create a database of databases. Super Brillant!
    And it's not like we never heard of any of those, though this one is based on the "A glass of wine and a fresh new database every day" approach. But its comments mention databases where there's a new database for every new customer.
  • fanha (unregistered)

    The real WTF is that this passed acceptance tests. Were the requirements testable? Did the tests pass? If so, what's the problem? What do you care if it's optimized as long as it meets performance requirements? Sure it's not the best under the hood, but if it's so bad that it was delivered non-functional and you didn't know, you failed at defining and enforcing testable requirements. And if having it architectured a certain way was going to be mandatory to maintaining it, that should have been specified as a requirement too and reviewed.

    Sounds like the programmers delivered a product that matched the requirements, on-time, on-budget, without engineering beyond what was necessary to meet the requirements (saving the client money assuming their requirements were accurate). No WTF there.

  • Zerbs (unregistered) in reply to Roy T.
    Roy T.:
    (Sorry for the mumbo-jumbo I'm not a native English speaker)
    Your English is much better than many so called native English speakers that I've come across.
  • (cs) in reply to JamesQMurphy
    JamesQMurphy:
    Um, I'm looking at this box:
    Copy the entire database of products to an Order database and an additional column 'quantity' is added (15,000 items total).

    I think that's supposed to be "... to an Order table", yes?

    So, either the site works properly only when one user is shopping, or every user gets their own personal table. Brillant.

    Don't count on it... what with the rest of the architecture of this Expert System, it may well make a whole new database for every order in progress. I barely know anything about databases and wow, I could probably do better than that in an afternoon :(

    The only reason I can think of for a system like this is if the consultants thought maybe the catalog changed so frequently and so much that the products didn't always have the same SKUs minute to minute. Otherwise couldn't they just make a table (or a row in a table of currently open orders) and list the SKUs for that order as they are added, instead of copying the whole table, adding a column, and modifying the result... what exactly were they thinking?

  • Superconsultant (unregistered)

    Where's the WTF? The process works flawlessly, HDDs cost nothing anymore, and performance isn't always a factor.

    Just think of all the hassle you'd have to go through to keep the orders consistant from a historic viewpoint. You might be forced to deal with versioning, item status and other ugly stuff...

    CAPTCHA: dolor - sit amet or what?

  • (cs)

    Let's see if I understand this. The busines logic is: o Write out a copy of the entire catalog o Troll all records for the ones the consumer wants o Flush any that have NOT been selected

    Makes sense to me!!

  • Roy T. (unregistered) in reply to fanha
    fanha:
    The real WTF is that this passed acceptance tests. Were the requirements testable? Did the tests pass? If so, what's the problem? What do you care if it's optimized as long as it meets performance requirements? Sure it's not the best under the hood, but if it's so bad that it was delivered non-functional and you didn't know, you failed at defining and enforcing testable requirements. And if having it architectured a certain way was going to be mandatory to maintaining it, that should have been specified as a requirement too and reviewed.

    Sounds like the programmers delivered a product that matched the requirements, on-time, on-budget, without engineering beyond what was necessary to meet the requirements (saving the client money assuming their requirements were accurate). No WTF there.

    Well for me the WTF was that the company explicitly sought after a respectable (thus) expensive company so that things like this wouldn't happen. And apparently the program did not get trough the tests because they started sending pdf's around instead of using the new system. (And I dare to say that management is not going to throw money away so easily).

  • Wickerman (unregistered) in reply to Alex G.
    Alex G.:
    I read through the flowchart, and I have this sudden urge to donkey punch people in the kidneys.

    I'm not sure you used 'donkey punch' in the correct context.

  • Candy (unregistered)

    I'd go for this solution as well. It's the simplest thing that could possibly work, fitting the requirements.

    The only way to point some customers to their silly requirements is by following them to the letter. There's no time requirement on this action, so we don't care. Literally.

  • Anon (unregistered) in reply to ParkinT
    Once the inner workings of the program were explained to management, the project was scrapped in favor of implementing a simple PDF catalog on CD where a customer would fill out a paper form and fax it into the order processing center where it would be hand entered.

    This seems like TRWTF to me. Sure the way the program is handling the data is completely retarded, but it doesn't seem like it would require that much effort to replace it with something more sane. It had a working UI already which might only need minor tweaking after you've replaced the database logic.

  • MT Guy (unregistered) in reply to Anon

    Hail hail. We're not talking about the finer points of orbit trajectories here, just the code used to:

    a) copy a database b) query items from new database c) delete records

    Changing those around to:

    a) use new user_orders table b) query items from existing database c) not delete records

    would have been a relatively simple undertaking.

  • fanha (unregistered) in reply to Roy T.
    Roy T.:
    fanha:
    The real WTF is that this passed acceptance tests. Were the requirements testable? Did the tests pass? If so, what's the problem? What do you care if it's optimized as long as it meets performance requirements? Sure it's not the best under the hood, but if it's so bad that it was delivered non-functional and you didn't know, you failed at defining and enforcing testable requirements. And if having it architectured a certain way was going to be mandatory to maintaining it, that should have been specified as a requirement too and reviewed.

    Sounds like the programmers delivered a product that matched the requirements, on-time, on-budget, without engineering beyond what was necessary to meet the requirements (saving the client money assuming their requirements were accurate). No WTF there.

    Well for me the WTF was that the company explicitly sought after a respectable (thus) expensive company so that things like this wouldn't happen. And apparently the program did not get trough the tests because they started sending pdf's around instead of using the new system. (And I dare to say that management is not going to throw money away so easily).

    They sought after a respectable expensive company so they wouldn't get their own requirements wrong and so the company would spend more of their money implementing features beyond the requirements instead of delivering a system which generates the highest feature-value for the lowest cost to the customer?

    No, that's what BAD companies do: deliver the wrong product on the wrong budget according to their own (wrong) imagined specs. The real WTF is blaming a company that got the job done to your requirements for the fact that you didn't ask for nor verify what you actually wanted.

  • Sakkie (unregistered) in reply to James

    Problem is, you'd generally check a custom-tailored suit to make sure there aren't staples and chewing gum.

    It's frightening how often companies just accept code from the likes of IB...Mmmm I mean "we named our building after ourselves" type companies without doing any kind of QA on it.

  • fanha (unregistered) in reply to Sakkie
    Sakkie:
    Problem is, you'd generally check a custom-tailored suit to make sure there aren't staples and chewing gum.

    It's frightening how often companies just accept code from the likes of IB...Mmmm I mean "we named our building after ourselves" type companies without doing any kind of QA on it.

    What makes you think this didn't pass QA? The client seemed happy, and it apparently met the requirements. QA's job isn't to test that the product is the best thing since sliced bread, its job is to test that the product meets the requirements.

    Of course, as long as clients continue to try to pass the buck for their bad requirements to programmers, programmers will continue to be "clever" and try to make "creative" "enterprise" solutions to problems, thinking that the solution that meets the requirements is insufficient.

  • Sam Tyler (unregistered) in reply to Charles400
    Charles400:
    It is 2009, and I'm working on a process that looks frighteningly similar to that flowchart.
    It is 1973 what is a web app?
  • (cs) in reply to Sam Tyler
    Sam Tyler:
    Charles400:
    It is 2009, and I'm working on a process that looks frighteningly similar to that flowchart.
    It is 1973 what is a web app?
    Something you apply to a spider web to kill the spider.
  • David Claughton (unregistered) in reply to fanha

    No, a BAD company is one that gives you exactly what you asked for.

    A GOOD company does analysis on the client requirements prior to starting development in order to ensure they are giving the customer what they actually need rather than what they think they need.

  • Americium (unregistered) in reply to fanha
    fanha:
    The real WTF is that this passed acceptance tests. Were the requirements testable? Did the tests pass? If so, what's the problem? What do you care if it's optimized as long as it meets performance requirements? Sure it's not the best under the hood, but if it's so bad that it was delivered non-functional and you didn't know, you failed at defining and enforcing testable requirements. And if having it architectured a certain way was going to be mandatory to maintaining it, that should have been specified as a requirement too and reviewed.

    Sounds like the programmers delivered a product that matched the requirements, on-time, on-budget, without engineering beyond what was necessary to meet the requirements (saving the client money assuming their requirements were accurate). No WTF there.

    Compare this process to a hand example. How does a human being solve this problem? Any method that makes an example person do too much is a bad algorithm.

    In this case, no person would copy all the products to a sheet of paper. Then, cross out any products he doesn't want. Finally, list the number of each product he does want. Therefore, this is a WTF.

    People write a list of the N products they want to buy. Then, they write down quantities. The list gets sent to the company to fill theat order. No program has to do more work than this.

  • fanha (unregistered) in reply to Americium
    Americium:
    fanha:
    The real WTF is that this passed acceptance tests. Were the requirements testable? Did the tests pass? If so, what's the problem? What do you care if it's optimized as long as it meets performance requirements? Sure it's not the best under the hood, but if it's so bad that it was delivered non-functional and you didn't know, you failed at defining and enforcing testable requirements. And if having it architectured a certain way was going to be mandatory to maintaining it, that should have been specified as a requirement too and reviewed.

    Sounds like the programmers delivered a product that matched the requirements, on-time, on-budget, without engineering beyond what was necessary to meet the requirements (saving the client money assuming their requirements were accurate). No WTF there.

    Compare this process to a hand example. How does a human being solve this problem? Any method that makes an example person do too much is a bad algorithm.

    In this case, no person would copy all the products to a sheet of paper. Then, cross out any products he doesn't want. Finally, list the number of each product he does want. Therefore, this is a WTF.

    People write a list of the N products they want to buy. Then, they write down quantities. The list gets sent to the company to fill theat order. No program has to do more work than this.

    Obviously, a HUMAN copying all the products would be ridiculous, as it would incurs hours of overhead and violate a time requirement. However, copying these items might take a couple seconds at most (presumably this was tested and didn't stand out as anomalous?), which does not violate a requirement. Optimizing is great when it's free, but the costs in engineering, coding, and testing for a more complex but "optimal" system are non-trivial. If it generates no significant value for the client (e.g. does fulfill requirements) but does cost them money, why would you do it?

  • SomeCoder (unregistered)

    I can't believe people are defending this.

    Anyone who knows even the very basics of a DBMS would know that the way the consultants did it was retarded.

    This is a very simple online catalog/shopping cart type of scenario. I can't really think of any way more retarded to do this than to require the customer to print out the finalized order form, take a picture of it (on a wooden table) and send it in to be manually processed.

    The story said that it passed requirements with test data. Presumably, the test data was much smaller than the actual data. Copying the entire database is stupid anyway but when you have a lot of data, the stupidity is mind boggling and I'm sure it won't pass performance metrics.

    As usual, The Real WTF(tm) are the comments.

  • Anonymous (unregistered) in reply to David Claughton
    David Claughton:
    No, a BAD company is one that gives you exactly what you asked for.

    A GOOD company does analysis on the client requirements prior to starting development in order to ensure they are giving the customer what they actually need rather than what they think they need.

    Not disagreeing with these statements but that obviously doesn't always happen in the real world. Sometimes what you need might change after you have to actually work with what you thought you needed. Hindsight is always 20/20 and there are lots of examples out there where someone goes back to work they previously did and asks themselves WTF they did it one way instead of another.

  • PublicLurker (unregistered)

    Is is just me or does the reference to a dialup modem make it look like this program actually copies the entire database to the users system (via dialup)does it's work and then sends back the result?

  • jkupski (unregistered) in reply to Charles400
    Charles400:
    It is 2009, and I'm working on a process that looks frighteningly similar to that flowchart.

    So much for the laugh I was just having...

  • (cs) in reply to Anonymous

    I have to agree that the company did provide what was asked for:

    1. Here's what we want the UI to look like.
    2. It should let the user enter the quantity of the items they want from the items we carry.

    Now, many here (myself included) might have come back with "How should the choose the item entered? A lookup, just let them enter a part number, what?". But there's a better than zero chance the consultants were just a front for coders 'elsewhere' who simply took the requirements and coded to them.

    So while it is practically useless in a real world setting, it is what was asked for.

  • (cs) in reply to ParkinT
    ParkinT:
    Let's see if I understand this. The busines logic is: o Write out a copy of the entire catalog o Troll all records for the ones the consumer wants o Flush any that have NOT been selected

    Makes sense to me!!

    You sir are my hero for today.

  • Travis (unregistered)

    I'm not in IT in any way, shape, or form. I'm a hobbyist programmer who came to TDWTF through a link in another programming forum and thought the stories were funny.

    Since then, I like to judge how much I'm learning about app development/being a programmer by how often I get the jokes (especially the CodeSOD stuff). My responses are usually:

    a) "I don't get it" or b) "Oh...yeah, I get it now. I see why that's weird"

    But today was the first day I had a gut-level, visceral "WTF". I guess I'm learning

  • Jadawin (unregistered) in reply to fanha
    Americium:
    Compare this process to a hand example. How does a human being solve this problem?

    Okay!

    << Place Order >>

    1. Pick up a printed copy of the catalog, which contains an order form at the back that is basically a list of all the part numbers, with a place to write in numbers.

    2. Rip out the order form from the catalog, sit it down next to the catalog.

    3. Flip through the catalog, writing down quantities as you find products you want.

    4. Interoffice order form to local Purchasing Dept.

    5. Did I forget something? Yes? Call purchasing, tell them to throw away the order form, I'll send them a new one; then repeat steps 1-4.

    It sounds like they DID model it from a human process, probably even based on what a user actually did.

  • (cs) in reply to Jadawin
    Jadawin:
    1. Pick up a printed copy of the catalog, which contains an order form at the back that is basically a list of all the part numbers, with a place to write in numbers.
    I have never in my life ever seen such an order form, except the "catalog catalog" where you circle the numbers of the catalogs that you want, and send it in with your payment (if any were not free).

    Every order form I have ever seen has "item #" and "item quantity", plus possibly other columns such as description (to check against the item # during processing), color, size, etc.

Leave a comment on “Consultants of the Crystal Citadel”

Log In or post as a guest

Replying to comment #244952:

« Return to Article