Oh, you wanted us to *FIX* it?

I am a programmer and we are developing an application in parallel with another organization. My job consists of taking stuff the other organization makes and working on our application to make them work together. This other organization, lets call them incompetent shit heads, or ISH for short, kept putting out unusable crap. After many battles and gnashing of teeth, we got them to agree to test their code before they sent it to us. Yes, you read that right. They weren’t testing their crap before sending it to us.

After much rejoicing on our end, the next release comes along. It is similarly crap. After pointing out several obvious mistakes and asking “WTF ISH, I thought you were going to test this crap”, we get an e-mail. ISH did test it, found a bunch of mistakes, and sent it to us anyways. If we want them to actually fix the mistakes, then they were going to have to push the deadline back. Project manager sees that, says nope, we don’t have time for that! Just use the shit and we’ll fix it in the next release.

Then I hear today, ISH is too far behind to test their code before sending it to us anymore. :smack:

If you guys are smart enough to fix ISH crap then why not just eliminate them at program your own crap from the start?

This would drive me crazy (and probably bring out my sarcastic side - “No, we just wanted the list of mistakes; we’re curious that way”).

I assume your company is looking for a competent partner to replace the smegheads at ISH?

FWIW:

Thank gawd we have the source.

I was hired (6 month contract) to install an A/R system and convert their data and feed programs to interface.
It ran. Barely. This was long before 7/24 proseccing - the system was taken offline and the batch processing started. Early morning, batch was done, and the system was put back online.

We had a 10 hour window. My estimate was that this (batch) system would require 28 hours to process.

It ended up having me call them and tell them program name, line numbers, and the code to go there instead of the crap they wrote.

I got fired 3 years later because I would admire the Emperor’s clothes.

The best part: the idiot manager had been told by their in-house IT department:
"2 years, $5 million, For the first 6 months he bragged about how brilliant he was - he got the system, ready to go, for $120K!
3 years and $6Million later, they gutted the thing of all the functionality (the reason for replacing the old stuff) and declaring victory.
This was Levi Strauss in 1986-1989.
They spent the 90’s giving everyone their own machines and feeding them whatever thay wanted.
By 2002, they were desperately trying to find out who had what, and if they should have it.

Update your resume.

Companies like that (or who allow managers like that) don’t last very long, and aren’t fun places to work. So be ready to go elsewhere. AEven transferring to another department might not be enough.

This sounds eerily familiar.

I’m currently part of a project to replace a system which was initially developed in the 1970s, and consists of a mainframe back end with a number of front end applications (mostly written in .NET) that interact with it. Primary work is being done by a contractor, with resident staff brought on board as needed.

Rollout is scheduled to happen in two phases: the first will replace the backend system, leaving the ancillary apps pretty much in place; the second will replace the ancillaries as well. As one might expect, during the interval between the phases interfaces are absolutely critical to ensure that customers see accurate information.

We’re now in the final countdown to first phase rollout, and the interfaces are crap. It took months to get the contractor to deliver files in the right format, and they have yet to deliver files with usable data. Finally they just stopped trying, arguing that the contract language only specifies that they deliver the right format with no mention of usability. And like treis’s situation, management has decreed that we declare the interfaces acceptable and do whatever it takes to make the data work. Problem is, the project has sucked up almost all the in-house staff, leaving one overworked developer and a part-timer.

I’m not a developer (thank Og), being more involved with making sure that the system hardware and software are configured properly and functional. Even so, I see much unpaid overtime and Rolaids in my future.

mrAru is currently working for a company that makes stuff for cell towers [cables, dehydrators and the like] and one of the sources for their dehydrators puts out seriously shitty product - and there is a definite lack of communication going on. The sales people will call down to engineering and ask if a particular change can be made, and the engineers will authorize it but not generate any supporting documentation [as one example] so the modified product will get shipped to mrAru to test his usual number and of course they all fail because they are now out of spec. He and I joke that if the days batches mostly passed the engineers were still locked in the basement, and if lots of them failed, someone let the engineers out of the basement. Lately if lots passed, the Chinese Government shot the lot of them and replaced them with competent engineers …

I’d hazard a guess that either the customer contracted with ISH to provide a part of the software, and with the OP’s company to provide the other part, and the two companies agreed to integrate their software as part of the contract, or, god help me, ISH is in fact the software department of the customer. The first case can be managed, though with difficulty. The second is usually unrecoverable.

The companies you guys are talking about - the know that “Dilbert” is not supposed to be a How To manual, right?

“Dilbert” is Scott Adams, former employee of Pacific Bell.
The strip went to hell when Mr. Adams decided Dilbert was enough money.

He quit his muse; the strip has gone straight downward since then.

You really need to see 36 well paid (6 figures each) drones sit in a meeting (attendance taken, any group which does not send a rep gets grief) being read a “status report” on some worthless project which will never be implemented to keep your sense of the insane.
I could still be there doing nothing but attending status meetings and saying “the OA group may require re-sizing our estimates if these changes are implemented”. The manager looked like she wanted to hug me when I told her of my contribution to the project. And it only cost her about $120 for the time I spent in that room.

I’ve had the argument more than once with project managers about what testing really is.

I now just insist that the end result of a finite period of application testing is not a working, signed-off application, it is merely a better appreciation of the stability and performance (or otherwise) of the software. At the end of a testing phase, it’s tested. Not ‘working’ - tested.

This explains much. Just this week I was marveling that the strip was using the exact same humor I was using in the 7th grade. And, it was stale then.

I haven’t read Dilbert in years but I was generally of the opposite opinion. Dilbert was funniest when completely unrelated to real office antics, because the reality hit too close to home.

I’m the DBA for our application. We get files from another program and upload them into our system. They are updating their app and it’s not going well.

They ask me to test some of the new files in our production database. WTF? Test in production? Are you out of your $%#&%$z mind? They are afraid that our test database isn’t exactly the same as our production database. BS.

Good thing that I didn’t test in production. Their latest files frequently don’t match the IDD (Interface Design Description) specs and won’t upload properly. It’s obvious when I open up the files that they are wrong so I don’t even try to upload them.

Next they tell me to upload the bad files as they want to see what will happen to our system if they send bad data. I say No. They’ve never had a problem with bad data in their old system. They want us to handle the issue of their bad data. Ain’t happening. Fix your crap.

Next their program manager tries to badger me into testing the bad data in our production system. Not no but HELL no. I call my program manager and tell him that the other PM bypassed him and is trying to get me to do something stupid. My PM is smart enough to back me up.

So as it stands now their program is about a month behind schedule; they can’t seem to fix the bad data; and they tried to blame me for the problems at a high level meeting. My PM bitch-slapped their PM at the meeting.