• fanha (unregistered)

    Downloading the database might seem like overkill in trivial scenarios, but it quite easily solves a number of problems. For example, if this is dial-up days, what if the connection drops? Here you only have one point at which the connection is needed at all, so isolating test scenarios is simple. However if you have to constantly have your application be able to compensate for a dropped connection, that's a significant amount more development and testing work. What about offline browsing of the catalogue (surely in the days of dialup, you don't want to clog your phone line the whole time you're browsing)?

    I see no reason to think why this could not have been thought of as the simplest and most practical way to engineer a solution to the general problem, even if it's not optimal for more trivial cases.

    Perhaps it wasn't tested on a production-size database? If so, why did the customer not do this before signing off the product as complete? The company was not even close to the main point of quality failure here.

    Of course, wouldn't expect any actual knowledge about practical engineering processes here, just a snobbery of heads-down coders who assume anyone who does something a "quick and dirty" way obviously "doesn't know how to code".

    No project has an unlimited budget, unlimited time to engineer, code, and test, and unlimited permission from the client to pursue things of little value. Tradeoffs happen, and the requirements are the guidelines. "Bad" tradeoffs which result in the requirements BEING MET (budget, time, functionality) are ALWAYS a problem with the requirements.

  • TODO: Enter Name (unregistered) in reply to SomeCoder
    SomeCoder:
    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.

    People aren't saying that this is a well-chosen solution. They are saying that it appears to be a working solution. As long as the overhead of transmitting copies of the database back and forth for every order is acceptable, there's no reason to throw this solution away. Stupidity under the hood is irrelevant as long as the user is happy.

  • Tom (unregistered) in reply to fanha
    fanha:
    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).

    The problem is that their product was probably highly efficient at what it did, but what it did wasn't scaleable. As long as you only copy a small database for a small number of users, you can probably conceal the problem with significant optimisation. Problem is, when you release it to 800 users on a catalogue of 60 products...

  • Tom (unregistered) in reply to Tom

    [Looks again] "15000 products". Ouch.

  • Tom (unregistered) in reply to fanha
    fanha:
    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?
    Ohhhhh, EVERYTHING that's wrong with what you've said here, starting with the fact that this isn't an optimisation issue, and that unless they tested the system with comparative amount of data (15,000? Unlikely) their problems will be at least O(n) (that "Ordered?" pass looks very dodgy).
  • (cs) in reply to Throknor
    Throknor:
    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.

    It doesn't matter how the order is entered. Copying all items from one table to another brand new table is an absolutely idiotic way of doing it, and has nothing to do with someone being a "front for coders" and has everything to do with the coders being BAD.

  • Jstacat (unregistered)

    It depends on the size of a typical order, a fastener supplier might have individual orders of hundreds or more small parts. Entering that type of order by hand could drive a company to pay top dollar for automation.

    [captcha= sagaciter] this may actually be a sagacious program.

    [Jstacat= not joined yet]

  • mh (unregistered)

    It's a "working solution" for sure, but I wanted to buy that 3 piece suit I wouldn't take a copy of every 3 piece suit in the store, bring them all home with me, mark the one I wanted, go through all of them individually and send back the ones I didn't want individually, then bring the one I wanted back to store and say "I want this one" (which is a "working solution" to the problem of buying a 3 piece suit by that definition).

    The reason this kinda thing gets through is that the senior manager who recommended/insisted on the Big Name Company in the first place is usually unwilling to lose face by admitting it's a crock of dog turd and ends up bullying it through. Acceptance tests be damned, we've paid $10,000,000 for this thing so we're going to USE it.

  • David (unregistered) in reply to Americium
    Americium:
    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.

    I want a...

    • credit card that's got no limit
    • big black jet with a bathroom in it
    • king sized tub big enough for ten plus me

    At some point you have to scan the list of products for validation. The only real WTF is presenting them all to the user in one giant list.

  • Terry (unregistered) in reply to snoofle

    Navigation was through a rigid tree style list, not a 15,000 entry list box. But that was almost worse because the categorization was such that, had it been say clothes being sold you could select by country/brand/style/size/colour but not be able to search just by size and style for example. It would have been hideously frustrating to browse.

  • (cs)

    Yesterday while investigating an nHibernate issue I came across an SQL statement containing 255 left outer joins...

    [edit]Crystal Citadel? I prefer the Combine Citadel [image]

  • Terry (unregistered) in reply to mh

    The VB front end all looked pretty enough, but functionally it was a disaster. The astonishing thing I heard later was that this was version 3, and the first 2 versions had been 'pretty rough'. Shudder.

  • fanha (unregistered) in reply to Tom
    Tom:
    fanha:
    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?
    Ohhhhh, EVERYTHING that's wrong with what you've said here, starting with the fact that this isn't an optimisation issue, and that unless they tested the system with comparative amount of data (15,000? Unlikely) their problems will be at least O(n) (that "Ordered?" pass looks very dodgy).

    No matter how you design it, if the user wants to browse offline (which is probably the general case when dealing with dialup), the whole catalog has to be downloaded. So there's no getting around that as the worst case. They just didn't optimize cases which don't need to be worst case to be better.

    If the requirements said it needed to work on a database of size X to effect Y, and it didn't, then that is a legitimate product issue. However, the article says no such thing was the case, as the only place the author says there was a problem was "under the hood". This indicates they signed off on a requirement which they never tested if the product met, or they failed to give such as a requirement; either way that's mostly if not wholly their fault.

    The article gives no information indicating performance was an actual issue (no rants about it taking forever), only the architecture.

  • Terry (unregistered) in reply to kastein
    kastein:
    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?

    It wasn't a web site, it was a standalone app. It was an order table though, and yes, the idea that there might be 2 orders happening at the same time was outside the possibility of reason. One order should be enough for anyone, right?

  • Cooksey (unregistered)

    They must have gone to their local Microsoft Certified Solutions Provider to get that monstrosity...

    Party on Garth...

  • Terry (unregistered) in reply to fanha
    fanha:
    Tom:
    fanha:
    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?
    Ohhhhh, EVERYTHING that's wrong with what you've said here, starting with the fact that this isn't an optimisation issue, and that unless they tested the system with comparative amount of data (15,000? Unlikely) their problems will be at least O(n) (that "Ordered?" pass looks very dodgy).

    No matter how you design it, if the user wants to browse offline (which is probably the general case when dealing with dialup), the whole catalog has to be downloaded. So there's no getting around that as the worst case. They just didn't optimize cases which don't need to be worst case to be better.

    If the requirements said it needed to work on a database of size X to effect Y, and it didn't, then that is a legitimate product issue. However, the article says no such thing was the case, as the only place the author says there was a problem was "under the hood". This indicates they signed off on a requirement which they never tested if the product met, or they failed to give such as a requirement; either way that's mostly if not wholly their fault.

    The article gives no information indicating performance was an actual issue (no rants about it taking forever), only the architecture.

    My original submission did :-) It would have been about 15 minutes to start an order on the PII hardware typical of the time. There was also no way to update the DB short of sending out a new CD.

  • fanha (unregistered) in reply to Terry
    Terry:
    My original submission did :-) It would have been about 15 minutes to start an order on the PII hardware typical of the time. There was also no way to update the DB short of sending out a new CD.

    That would be a pretty bad problem then. :)

  • Jo (unregistered) in reply to James

    Something like "If any part of this project gets published on thedailywtf.com we will not pay."

  • Steve (unregistered) in reply to DaveK

    Thanks mate! Now I'm guilty of child abuse.

  • Old Fart (unregistered) in reply to SomeCoder
    SomeCoder:
    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.

    Clearly, that's what really keeps us coming back... ;)

  • (cs) in reply to MT Guy
    MT Guy:
    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

    Per user and order, of course.
  • (cs) in reply to Travis
    Travis:
    But today was the first day I had a gut-level, visceral "WTF". I guess I'm learning
    Welcome to the Dark Side... muahahahahahaaaaaa!
  • Adrian Pavone (unregistered) in reply to Old Fart
    Old Fart:
    SomeCoder:
    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.

    Clearly, that's what really keeps us coming back... ;)

    I never feel that an article has been read until I have looked at every last comment. They are just, for the most part, so amusing, immature and un-knowledgeable :).

  • blunder (unregistered) in reply to fanha
    fanha:
    Downloading the database might seem like overkill in trivial scenarios, but it quite easily solves a number of problems. For example, if this is dial-up days, what if the connection drops?

    You almost sound serious about this, so I'll bite. If you lose your connection, then you shout downstairs for someone to put the phone back on the hook. Then you start the order over. This isn't a Mars landing, no one's gonna die if you lose contact. I'm sure people with dial-up do just fine on Amazon.

  • methinks (unregistered) in reply to Zerbs
    Zerbs:
    Roy T.:
    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)

    Your English is much better than many so called native English speakers that I've come across.

    Welllll... his english is "definately" a little bit "flawwed" in places ;o)

    And I'm saying this as a non-native speaker...

    (Note: I re-added the italic part, which was left out by Zerbs)

    But basically you have a point, Zerbs - mixing up e.g. there/their/they're or its/it's is "definately" (and somehow surprisingly) more frequently done by native speakers (as is writing "definately" instead of "definitely", at that ;o))

  • methinks (unregistered) in reply to fanha
    fanha:
    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?

    Excuse me, but this is hardly an issue of "optimizing", be it free or not. The copying might only take seconds now, but what if the product database multiplies in size?

    In other words, this is the exact opposite of a scalable solution, which means it was incepted/planned/engineered simply plain wrong from the start, and no viable optimization will be possible later without changing the whole concept and thus major parts of the codebase.

  • The 2-Belo (unregistered)

    I sure hope they were planning to run that thing on one hell of a beefy supercluster, because... I mean, holy crap, dudes! 15,000 records copied per user per order? And this company had so many orders it didn't know what to do with them all? What the f

    **Error: Database server not responding.

  • methinks (unregistered) in reply to fanha
    fanha:
    Downloading the database might seem like overkill in trivial scenarios, but it quite easily solves a number of problems. For example, if this is dial-up days, what if the connection drops?

    And now please care to explain why downloading much more data (i.e. the whole 15.000+ products catalog, mind that this operation was done for each order per user!) reduces the probability of the connection to drop or the problems if it does drop?

    Quite the contrary, if you only transfer the necessary data and keep track of the state on the client side, the probability of getting across the needed data in decent time increases a lot.

    Moreover, a connection drop while transferring a binary and/or complex structure like a whole database is much more serious than a loss of a small and simple structure like a single product record.

  • (cs) in reply to snoofle
    snoofle:
    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.
    That would be awesome. I wonder how the workflow goes with that. Use app, turn on power, clean up spider ?
  • (cs)

    TRWTF is that the photo of the building has an alternate text "Photo Credit: 'Thristian' @ Flickr" instead of some meaningful description

  • (cs) in reply to snoofle

    pls can you send me,whatdo you mean by timesheet and lmportant of timesheet,and why l will want it very fast

  • Rocketeer (unregistered)

    Hmm, this flow reminds me of a process in the application I support and maintain...

    However, in our application (which shall remain nameless), there are two options: Creating a "Full" order, and creating an "Empty" order.

    An empty order is basically an order header; the user creates the header, then can use a wide range of search options to add items to the order.

    If you create a full order, it does pretty much what the WTF does; creates an order header, then adds every product available to the user to the order details table. The user can then select quantities in the UI, and when he saves it, any un-ordered products are removed.
    However, if after saving, the user decides he wants to add more products, it just uses the logic from the Empty order - it doesn't copy the full list again.

    The reason our logic isn't quite a WFT is firstly that we have a choice, and secondly the restriction that only products available to the user are included in a Full order. A fairly common retail situation is where the store has a small range, and orders at least one of almost everything (think a store placing an order from the Coca-cola supplier - there's only half a dozen products, and he wants most of them). In this case, having the full list available (so the user just types in quantities, no product codes) is a great bonus.

    Of course, the WTF for our product is when users complain that creating an order takes too long. 99% of the time, it's because they've decided to create a full order from a major warehouse supplier - even though all they want is one item!

  • Anonymous (unregistered) in reply to charonme
    charonme:
    TRWTF is that the photo of the building has an alternate text "Photo Credit: 'Thristian' @ Flickr" instead of some meaningful description
    Do you honestly consider that to be the primary WTF on display here? Do you even work in IT?
  • Arnold (unregistered)

    What?? They stole my design! (and they sell it overpriced too..)

  • Arnold (unregistered) in reply to fanha
    fanha:
    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).

    So you are saying that the customer is to blame for not making clear their requirements and THEREFORE the developer is excused to deliver an implementation with serious flaws in most of the real life cases.

    You are right about one thing: customer silly. But.. where's your honour? Please remind me never to let you develop any applications for me.

  • (cs) in reply to DaveK
    DaveK:
    There was obviously one requirement missing from Terry's spec:
    • Make it not crap.

    One of the most important official requirements (right in the Marketing Requirements Doc) on the last project I worked on was:

    • The UI shouldn't suck

    It was mostly in there as a jab at the so-called UI design experts who were trying to turn a simple functional application into the epitome of style, flash, and web-2.0-ness. I ended up quoting it a lot when talking to them.

    On a related-yet-not-IT topic, I dabble in community theater. One director's pre-perfomance pep talk consisted of a single sentence: "Try not to suck." It worked remarkably well.

  • (cs) 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.

    Ah, another instance of Joseph's Law, which I invented at my first out-of-college job and named for a customer after a particularly difficult project:

    99% of the time, what the customer asks for and what the customer wants are two entirely different things.

    In this case, they had asked for a custom report which could only be done with an O(n-cubed) algorithm. Since n was in the millions, and this was in the late 80's on slow hardware, it took a very long time to run. When we gave it to them, they said "no, that's not what we meant". Turns out that what they actually wanted could be done in O(n).

    Bad on me, the analyst, and the company for not analyzing and validating the requirements. Good for me that I learned the lesson so early in my career and have applied it since. Knowing the analyst and the company, I doubt they learned much ...

  • WW (unregistered)

    What's the point of using a database in the first place if you just iterate through the records anyway? I have seen a better (more efficient, more scalable, more robust, more easily maintained) order system than this written by one guy in less than a week.

  • SpecNAZI (unregistered) in reply to Terry

    WTF this process was not in the spec in the first place? I don't get it, I would be ashamed to post this and point fingers, you let it happen.

  • (cs) in reply to RobFreundlich
    RobFreundlich:
    One of the most important official requirements (right in the Marketing Requirements Doc) on the last project I worked on was:
    • The UI shouldn't suck

    It was mostly in there as a jab at the so-called UI design experts who were trying to turn a simple functional application into the epitome of style, flash, and web-2.0-ness.

    I bet when you got your marketing department to sign off on it, they thought that was exactly what "not suck" *did* mean!
  • mh (unregistered) in reply to SpecNAZI
    SpecNAZI:
    WTF this process was not in the spec in the first place? I don't get it, I would be ashamed to post this and point fingers, you let it happen.
    Pshaw, and pfffft even.

    Don't tell me that you would deliberately develop crap software for a client if the spec allowed you to.

    I think from your name that you're just joking here; I hope I'm right.

  • (cs) in reply to DaveK
    DaveK:
    RobFreundlich:
    One of the most important official requirements (right in the Marketing Requirements Doc) on the last project I worked on was:
    • The UI shouldn't suck

    It was mostly in there as a jab at the so-called UI design experts who were trying to turn a simple functional application into the epitome of style, flash, and web-2.0-ness.

    I bet when you got your marketing department to sign off on it, they thought that was exactly what "not suck" *did* mean!

    Actually, the two guys from Product Marketing that I worked most closely with were remarkably clueful. They usually backed me up in "discussions" with the "design experts".

    Unfortunately, after a while the above statement became the only good thing about that company, and I moved on.

  • a saucy lad (unregistered) in reply to fanha

    The design in the article is not just "non-optimal", it is downright idiotic. It's a laughably awful design and that's why it's on this site. Why are you trying to defend it?

    I would certainly not want to contract you to write any code. "Even if the code is nonsensical crap, if it fits the spec it's fine!"

  • a saucy lad (unregistered) in reply to a saucy lad

    whoops, forgot this

    fanha:
    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).

  • John Muller (unregistered) in reply to Terry

    "But that was almost worse because the categorization was such that, had it been say clothes being sold you could select by country/brand/style/size/colour but not be able to search just by size and style for example. It would have been hideously frustrating to browse."

    That's what I hate about clothes shopping...

    Items are arranged by maker/style/color, with different sizes in one pile.

    As much as the clothing makers would like to think I'm shopping for their brand, I am in fact shopping foremost for something that fits, and within that contraint sytle/colors/branding may be considered.

    I would love to go to something like a shopping mall with each stall containing, for example, 'Size 34 mens pants', 'Large mens shirts'... pawing through a pile of 30, 32, 36, 38, 40... sizes does no good if I'm size 34.

  • Hmm (unregistered)

    "Copy the entire content of the orders ... add quantity column ..."

    Ever hear of normalization?

    The old adage applies: Throw hardware at a slowness issue you increase performance by 50% Throw software tuning at a slowness issue, you get 1000% increase.

    A 15,000 record insert PER SESSION? Holy shiznit.

  • (cs) in reply to John Muller
    John Muller:
    That's what I hate about clothes shopping (..) I would love to go to something like a shopping mall with each stall containing, for example, 'Size 34 mens pants', 'Large mens shirts'... pawing through a pile of 30, 32, 36, 38, 40... sizes does no good if I'm size 34.
    You sir, are my hero.
  • (cs) in reply to Terry
    Terry:
    Navigation was through a rigid tree style list, not a 15,000 entry list box. But that was almost worse because the categorization was such that, had it been say clothes being sold you could select by country/brand/style/size/colour but not be able to search just by size and style for example. It would have been hideously frustrating to browse.

    Sounds like the ordering system in place for government schools in my home state... It had no search function, items were only allowed to exist in exactly one category and there was some overlap in category names. Simply placing an order for a box of pens could take hours if you don't already know which category the ones you want are in.

  • Watson (unregistered)

    You had me at "Copy the entire database".

    CAPTCHA: prominantly

  • (cs) in reply to DaveK
    DaveK:
    There was obviously one requirement missing from Terry's spec:
    • Make it not crap.

    Also, frist!

    I think that those big consulting companies lack one teensy weensy thing that's really, but really needed in those scenarios: and actual end user. It's a shame, really, when I'm using various on-line electronics distributors and it seems some of their, um, ordering systems could be replicated by a teenage php leet coder with an ODBC connection to "the Oracle" set up... Usability at its, ekhm, best.

    But hey, DigiKey recently moved from a screen-scrapped system seemingly designed by a COBOL-speaking retiree with lots of big iron experience, to... the same effing thing, this time done in ASP.NET. While I do praise them that they take it step by step towards the state of the art, their ASP.NET skills still leave something to be desired... mostly in usability department ;)

    Cheers, Kuba

Leave a comment on “Consultants of the Crystal Citadel”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article