Comment On Consultants of the Crystal Citadel

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

* Make it not crap.

Also, frist!

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...

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 ..."?

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.

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

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.

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.

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.]

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.

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?

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.

DOA:

DaveK:

DOA:

Why, you little...

ITYM "Why, I oughta ..."?

Think Homer Simpson

Oh....

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.

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.

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)

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!

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.

SLA

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.

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!

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.

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.

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.

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.

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?

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?

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!!

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

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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?

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.

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.

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?

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...

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.

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.

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

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.

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.