Official thread for venting on boneheaded design, engineering, or policy decisions.

Commence facepalms.

-We're required to write an interface for every business object class we write regardless of how far down the hierarchy it is.

-Client localization data is totally and completely stored on the DB, every time you open a dialog you have to wait for the localized text from the DB.

3/31/2011 3:16:35 PM

An accounting system that will not be named stores pointers on each financial transaction meant to record which user created and which user last modified it, but there is no foreign key relationship between the transaction table and the user table because the precision of the column on the transaction table does not match the precision of the primary key column on the user table.

[Edited on March 31, 2011 at 3:47 PM. Reason : ...]

3/31/2011 3:46:21 PM

Buy a new game. Comes included with DLC. Can't load my saved game cause the server that verifies the DLC is down .


Fuck the pirates and the developers.

4/8/2011 9:02:51 PM

I wish you guys knew Labview...by the time myself and another guy are done, we'll have ripped out over 1000 different VIs and likely swapped out 10 different data acq boards and replaced it with a properly working implementation.

4/8/2011 11:23:53 PM

the ipod shuffle with no controls (3rd gen maybe?)

4/9/2011 7:04:10 PM

site_crazyweb.aspx

Had to be said.

4/9/2011 7:31:06 PM

My department at work has a home-brewed tool for entering the budget that was written in VB6 circa 2001. Rather than do a complete re-write in .NET, they used a conversion tool and in turn released a buggy piece of junk to production.

The acceptance testing defect log had almost 50 unique known bugs, but they decided none were "show stoppers" and went production anyway.

4/9/2011 9:04:07 PM

I wish I was allowed to speak in this thread

4/9/2011 10:30:14 PM

iTunes

4/10/2011 12:36:00 AM

4/10/2011 3:15:10 AM

Quote :

"My department at work has a home-brewed tool for entering the budget that was written in VB6 circa 2001. Rather than do a complete re-write in .NET, they used a conversion tool and in turn released a buggy piece of junk to production. "

I feel your pain. We still activly develop using the ATL/MFC structure and using MS C++ 6.0 as our development IDE. Bastards are too cheap and lazy to bother trying to advance at all.

4/10/2011 10:08:38 AM

^i'm glad you got to get into this software crap you like so much and i got to get out of it.

4/10/2011 11:48:31 AM

^^ I'll never understand why companies do that


actually I will... people balk at what seems like a large short-term expense because they have no idea how to amortize an investment and dont realize that it generally costs more to maintain old shit

4/10/2011 8:51:03 PM

Quote :

"people balk at what seems like a large short-term expense because they have no idea how to amortize an investment and dont realize that it generally costs more to maintain old shit"

QFMFT

4/10/2011 9:02:58 PM

If you're worried about posting juicy bits from work you can PM them to me and I'll be your proxy

4/11/2011 5:27:58 PM

a vendor wrote a program that logs instrument data such as tank levels and alarm data using MS SQL as the back-end. Every day the program creates a *new* SQL database for the log. Not a new table. Not new records. A. New. Fucking. Database.

4/11/2011 7:25:05 PM

[Edited on April 11, 2011 at 7:54 PM. Reason : apparently tww doesn't like ?_?]

4/11/2011 7:53:17 PM

a long while back, we used to have to log all tests in an access database. im guessing that a non-programmer created it (at least I hope) because it was terrible.

It had a wonky VB macro that took forever to look up a trainee. if they didnt exist in the system and you tried to create a new trainee record, it would crash. every time. thankfully when you reopened (took 2-3 minutes at least), that record would now exist.

4/11/2011 7:55:33 PM

^^Learn numeric character references.

4/11/2011 8:43:52 PM

Quote :

"a vendor wrote a program that logs instrument data such as tank levels and alarm data using MS SQL as the back-end. Every day the program creates a *new* SQL database for the log. Not a new table. Not new records. A. New. Fucking. Database. "

Ahahahahaha

4/11/2011 11:07:15 PM

Quote :

"NEW FUCKING DATABASE"

4/11/2011 11:59:20 PM

Intuit Health's practice management website builder thingy uses a 3rd party text editor which was last updated in 2002. The most interesting bug related to this is when you click inside the editor's text box, all the content sometimes automatically doubles on itself and doesn't let you delete the duplicated text. Drives me nuts.

4/12/2011 12:59:31 AM

4/12/2011 7:58:47 AM

that's still done today by Adobe, with things like Norton Security Scan, some shitty McAfee product, the Google Toolbar, and also Google Chrome offered along with the Shockwave Player

4/12/2011 10:00:15 AM

Quote :

""a vendor wrote a program that logs instrument data such as tank levels and alarm data using MS SQL as the back-end. Every day the program creates a *new* SQL database for the log. Not a new table. Not new records. A. New. Fucking. Database.""

lol +1

A conditional statement of If not exists before the create database statement in the stored procedure is all that is needed in their SQL script, followed by some conditional inserts with @keys.

Quote :

""people balk at what seems like a large short-term expense because they have no idea how to amortize an investment and dont realize that it generally costs more to maintain old shit""

Same shit, different company. We would rather update our ancient Foxpro internal tracking system (Yes, Foxpro 9) rather than re-write it in .NET.

[Edited on April 12, 2011 at 11:30 AM. Reason : -]

4/12/2011 11:28:49 AM

no, the new database is intentional. they mean to create a new database for every fucking day.

4/12/2011 2:17:43 PM

^anything that stupid has to be intentional

4/12/2011 2:48:12 PM

Quote :

"We would rather update our ancient Foxpro internal tracking system (Yes, Foxpro 9) rather than re-write it in .NET. "

FOXPRO?!?!?!?!

4/13/2011 2:23:37 AM

Yes, Foxpro. There is no end to managerial stupidity.

4/13/2011 8:02:31 AM

I may have Foxpro beat, See OpenRoad 95!! We're still developing in it.

If you know what that is you know how shitty it is, if you don't theres a reason why.

4/13/2011 10:20:02 AM

The program assigns a unique numeric identifier to most records. This identifier is the primary key on those objects' tables. Some records have a shorter alphanumeric code for the benefit of humans who work with them. This alphanumeric code is also unique.

Items created in volume, like financial transactions, typically don't get the human-friendly codes. Items that are fairly persistent and discrete, like general ledger accounts, do.

In at least two instances, the wires have been crossed such that objects created in volume—purchase orders being one—are also assigned a short code.

Unlike most other objects, this short code is set to the value of the numeric identifier. Like usual, it must be unique.

What do you suppose happens when the short code doesn't match the numeric identifier—perhaps because of a bad import—and a new record is created with a numeric identifier for which a corresponding short code already exists?

Extra credit: Can you anticipate any problem that might arise as a result of the numeric identifier having a precision of 21 digits...and the short code being 8 fixed-length characters?

[Edited on April 13, 2011 at 10:42 AM. Reason : already]

4/13/2011 10:42:05 AM

Quote :

"We would rather update our ancient Foxpro internal tracking system (Yes, Foxpro 9) rather than re-write it in .NET. "

It's all about value vs. resources. Especially with Legacy applications. As much as I hate to admit it, financially it doesn't always make sense to update legacy software JUST because it's on some ancient technology.

4/13/2011 11:35:39 AM

ya'll gonna think I'm crazy, but I intentionally migrated our planning system to an ancient WebCollab system. Mostly because it's tables and simple layout works like money on mobile phones without having to zoom 500 times to get something done

4/13/2011 12:15:13 PM

nothing wrong going with something old, no sense over engineering something just for the sake of fitting whatever is modern at this point in time.

4/13/2011 1:00:52 PM

Quote :

"What do you suppose happens when the short code doesn't match the numeric identifier—perhaps because of a bad import—and a new record is created with a numeric identifier for which a corresponding short code already exists?"

Perhaps the records load with the data from a different record, making it incorrect, but possibly appearing correct? Duplicate keys errors or Unique constraint errors on the Primary Key resulting in a crash?

[Edited on April 13, 2011 at 1:46 PM. Reason : -]

4/13/2011 1:45:27 PM

Quote :

"Extra credit: Can you anticipate any problem that might arise as a result of the numeric identifier having a precision of 21 digits...and the short code being 8 fixed-length characters? "

Just guessing... Once the values begin to exceed 11111111xxxxxxxxxxxxx, they will be forcefully linked to the "11111111" records. When the first 8 digit values change "11111112" the pattern continues. I'm not sure exactly how many records would be inappropriately smashed together as a result, but it looks like a real data clusterfuck to me.

4/14/2011 8:36:49 AM

Stimwalt said:

Quote :

"Perhaps the records load with the data from a different record, making it incorrect, but possibly appearing correct? Duplicate keys errors or Unique constraint errors on the Primary Key resulting in a crash?"

Yeah, in my specific scenario, the short code must be unique, so the insert actually fails. The program's lack of error handling for this scenario means no new purchase orders can be created until the data issue is resolved.

If a record is created with a short code that doesn't match the numeric identifier but is still unique, you get unexpected results based on what you're trying to do (look up that particular purchase order, run a report with the affected PO in its range, etc.).

Stimwalt said:

Quote :

"Just guessing... Once the values begin to exceed 11111111xxxxxxxxxxxxx, they will be forcefully linked to the "11111111" records. When the first 8 digit values change "11111112" the pattern continues. I'm not sure exactly how many records would be inappropriately smashed together as a result, but it looks like a real data clusterfuck to me."

We haven't actually hit this yet because it won't occur until a user tries to enter the one hundred millionth purchase order, but I suspect it will fail because a purchase order record with the numeric identifier 10000000 got created with short code 10000000 already. When that happens, users won't be able to enter more POs.

4/14/2011 9:04:27 AM

A million po's?

Unless we are talking about Unisys or the federal government or something, when do you anticipate hitting this limit given your company's current usage?

4/14/2011 11:38:20 AM

It's not my company's usage. It's our clients' usage. In some cases, they've got a 20-year head start.

4/14/2011 12:46:43 PM

^ah, so PO's never get cleared/removed from the system? Yeah that could be a problemo

4/14/2011 6:23:22 PM

Quote :

"Yes, Foxpro. There is no end to managerial stupidity."

A place I work at uses a program to determine the price of an order and to keep track of customer records that uses a Visual FoxPro back-end.

4/14/2011 9:32:58 PM

The web site we use to log billable hours requires authentication. Here's the path for a successful login.

1) Pop-up prompts for user id and password
2) You enter correct credentials, and click submit.
3) An error beep sounds and the password field is cleared, leaving the user id populated. The password filed has focus and allows input (not disabled).
4) There's a long pause and you are finally granted access.

So basically you think you've put in the wrong password after step #3, so before you get accustomed to the stupidity you'll try to reenter your password and resubmit.

[Edited on April 15, 2011 at 9:12 AM. Reason : -]

4/15/2011 9:11:20 AM

Found this "Easter Egg" today in some code I am reviewing.

Quote :

" #Region "egg" Public Function Egg() As Integer L("Did you hear? Osama's keeping any eye out for those 72 virgins!") Return 666 End Function #End Region "

also, the guy who wrote that crap has never heard of SQL injection

10/18/2011 9:13:59 AM

And I thought my easter eggs were lame (e.g. full screen unicorn background for one of our team members; always comes up during meetings).

10/18/2011 3:16:30 PM

Quote :

" try { // bunch of code here } catch (Exception ex) { throw; } "

at least they were nice enough not to use the exception variable, so I could find this abomination via the warning. after wading through the other 400 warnings in the project.

5/2/2012 10:47:28 PM

also, this was great yesterday. We've got an application that essentially hosts a bunch of other applications and manages security settings, new deployments, roles, and a few other common pieces. This application has a management console that is configured to send a restart command to the application on all machines so that it can force updates. Well, the application also allows you to save a "default workspace" which will automagically load up windows and sub-applications to however you want. pretty convenient, except it doesn't allow you to stagger the loading of the sub-applications or the workspaces. So, it sends the restart command to all machines at the same time, all apps restart and update, and then load their default workspaces. Think 500-700 users, on a massively data intensive application (poorly designed in many respects, too, but that's another story).

As you might expect, this causes a massive spike in server utilization shortly after the restart. Well, our sub-application uses email messages to a distribution list on a common email-account for some of its error reporting. The distribution email address sends the message to a good 40-50 people, maybe more. When the server gets slammed with reload data requests, it backs up big time, triggering timeouts on 300-400 machines, which, predictably, generates email messages. This is where it gets good. The application requests data in a queue fashion, one data piece at a time (IIRC) in some cases, so each data request hits the timeout, on the order of 500-600 per machine. All of those fuckers time out; and send an email message to the distribution list. So, 500-600 machines send 500-600 email messages, all at the same fucking time to a single address, which then gets distributed out to about 40-50 people. To make matters worse, the slamming of the server kills the application connections on all the machines, and the only solution to that is to shut down the main application. If you don't, then the sub-apps keep trying to connect with the broken connections, thereby generating even more emails.

All this happens in the span of about two minutes. The Exchange server hits a screeching halt. For the entire company, possibly all over the world. It's taking in all the emails into a queue, but it can't keep up sending them all out, so the queue backs up. The application has a try-catch block around the sending of the error emails in case something goes wrong. Since the Exchange server is now slammed, the timeout for sending the emails and getting back a positive response trips, which causes more emails to be sent to other fallback addresses, from every machine, for every data request. In the span of about 5 or 6 minutes, over 100000 emails are generated and sent out to 50 recipients, each.

Now, a lot of people have blackberry phones with their outlook accounts synced to it. So that's even MORE emails being sent out. Not to be outdone, my boss has at least one rule on his inbox set up to forward a subset of emails out to the entire team and QA staff. So he's adding insult to injury by spamming people's inboxes with over 30000 additional emails, further gumming up the system. He kills the rule, but it's server side, so the rule has already been applied to whatever emails have reached his inbox. However, the emails are only sent out when his machine is running outlook, so he just turns it off and hopes it will go away.

But, no. Four hours later, he fires up his email client and proceeds to continue processing all of the emails, spamming everyone again. Awesome fucking day.

5/2/2012 11:00:42 PM

That sounds like the type of load I generated with a custom tool designed to drive IO load for an Exchange server by creating few thousand accounts and then spam each other back and forth .... yeah, it can bring a server to its knees--intentionally on my part, not so on yours. Ouch. Looks like I should've asked you for that program, haha.

5/3/2012 12:08:09 AM

I'm currently in the world of test. One tester with a gung-ho spirit reads tons of books about testing so that she can get promoted. She read that every single test case must only be able to fail for a single reason, so she makes this a HUGE issue and spearheads the effort.

I somewhat agree with this approach except for one thing...
We don't have any time designated to creating automated tests, so it is assumed that all tests are manual tests. The rule for one fail per case really applies to an automated world due to all the overhead from like 10,000 test cases per project. These include like 20 tests for each button (click up action, click down action, mouse over, right click, etc).

Case in point, she lead a project immediately after spearheading this where a program could send one status to another program. It could be one of 3000 numbers (1-3000), so she created 3000 test cases for this. All you were doing was setting one a number in a program and sending it to another. Two weeks later with and two testers were still only 50% finished with those tests. Zero failures, so management pulled the plug on those.

Her whole project turned out to be a huge disaster riddled with quality issues because they spent so much time dicking around with those fluff tests. Our boss took flack, and in turn gave the whole team as a generic group flack (never even blamed her). Six months later she was promoted for taking initiative.

5/3/2012 12:20:54 AM

guess she skipped the chapters on boundary conditions

5/3/2012 12:27:47 AM

^^she's a fucking idiot. She would be laughed at and ridiculed and likely terminated for actually implementing something like that in my product group.

We automate the shit out of everything test wise. But even with thousands of automated tests that run on each CI build, there is a ton that gets missed. Test automation is great for code contract enforcement, security standards, testing for known loopholes and weaknesses, etc.

5/3/2012 1:47:54 AM