Worst collaboration experience story?

I was not directly involved, it was a Delphi -> C# conversion of our customer returns application.

The dev manager was out to prove waterfall was the only development methodology that could make convert the monolith app to a lean, multi-tier, enterprise-worthy application.

Starting out with a team of 7 (3 devs, 2 dbas, team mgr, and the dev department mgr), they spent around 3 months designing, meetings, and more meetings. Armed with 50+ page specification Word document (not counting the countless Visio workflow diagrams and Microsoft Project timeline/ghantt charts), the team was ready to start coding.
The database design, workflow, and UI design (using Visio), was well done/thought out, but problems started on day one.
- Team mgr and Dev mgr split up the 3 devs, 1 dev wrote the database access library tier, 1 wrote the service tier, the other dev wrote the UI (I'll add this was the dev's first experience with WPF).
- Per the specification, all the layers wouldn't be integrated until all of them met the standards (unit tested, free from errors from VS's code analyzer, etc)
- By the time the devs where ready to code, the DBAs were already tasked with other projects, so the Returns app was prioritized to "when we get around to it"

Fast forward 6 months later, all the devs were 'done' coding, having very little/no communication with one another, then the integration. The service and database layers assumed different design patterns and different database relationships and the UI layer required functionality neither layers anticipated (ex. multi-users and the service maintaining some sort of state between them).

Those issues took about a month to work out, then the app began beta testing with real end users. App didn't make it 10 minutes before users gave up. Numerous UI logic errors, runtime errors, and overall app stability. Because the UI was so bad, the dev mgr brought in one of the web developers (she was pretty good at UI design). You might guess how useful someone is being dropped in on complex project , months after-the-fact and being told "Fix it!".

Couple of months of UI re-design and many other changes, the app was ready for beta testing.

In the mean time, the company hired a new customer service manager. When he saw the application, he rejected the app because he re-designed the entire returns process to be more efficient. The application UI was written to the exact step-by-step old returns process with little/no deviation.

With a tremendous amount of push-back (TL;DR), the dev mgr promised to change the app, but only after it was deployed into production (using "we can fix it later" excuse).

Still plagued with numerous bugs, the app was finally deployed. In attempts to save face, there was a company-wide party to celebrate the 'death' of the "old Delphi returns app" and the birth of the new. Cake, drinks, certificates of achievements for the devs, etc.

By the end of the project, the devs hated each other. Finger pointing, petty squabbles, out-right "FU!"s across the cube walls, etc. All the team members were re-assigned to other teams to separate them, leaving a single new hire to fix all the issues.

Longest I've worked without rest + why?

Over 24 hours. Why?

In our old system, the database had fields, for example, a customer like Total97, Total98, etc. to store values by year (or some date-specific value).

Every January 1, we had to add fields to accommodate the upcoming year and make the appropriate code changes to handle the new fields.

One year the UPS shipping rates changed and users didn't want to 'lose' the old rates, so they wanted new fields added (Rate98, Rate99, etc) so they could compare old vs. new. That required a complete re-write of most of the underlying applications because users wanted to see the difference on any/all applications that displayed a shipping rate. I'll throw in asking 'why?' was often answered with "because we pay you to do what we say". Luckily, we had already gotten to work on a lot of this before January 1st, so we were, for the most part, ready.

January 1st rolls around (we had to be in the office at 3:00AM), work thru changes, spend some time testing, and be done before noon. That didn't happen. The accounting system was a system that wasn't in (and had never been) in scope, and when we flipped the switch, one of the accountants comes into the office:
E: "Guys? None of our Excel spreadsheets are working. They are critical to integration with the accounting software"
Us: "What? Why would you be using Excel to integrate with the software instead of their portal?"
E: "We could never figure it out, so we had a consultant write VBA scripts to do the work."
Us: "OK, a lot of fields changed, but shouldn't be a big deal. How many spreadsheets are we talking about?"
E: "Hundreds. We have a separate spreadsheet for every integration point. The consulting company said it scalable, whatever that means."
Us: "What?! Why we just know hearing about this!?"
E: "Don't worry, the consultant said making changes would be easy, let me show you, just open the spreadsheet..click here..<click><click><click>...ignore that error, it always happens...click that <click><click><click>.."
Us: "Oh good lord, this is going to take hours"
E: "Ha! Probably. All this computer stuff is your job and I've got a family to get to. Later"
Us: "Hey 'VP of IS', can we go home and fix these spreadsheets as-needed this week?"
VP-IS: "Let me check with 'VP-FS'"
<few minutes later>
VP-IS: "No, he said Excel is critical to running their department. We stay until Excel is fixed."
Us: "No, no...its these spreadsheets. I doubt FS needs all of them tomorrow morning."
VP-IS: "That's what I said. Spreadsheets, Excel, same thing. I'll order the pizza. Who likes pepperoni!?"

At least he didn't cheap out on the pizza (only 4 of us and he ordered 6 large, extra pepperoni from one of the best pizza places in town)

One problem after another and we didn't get done until almost 6:00AM. Then...

VP-IS: "Great job guys. I've scheduled a meeting at 8:00AM to review what we did so we can document the process for next year. You've got a couple of hours. Feel free to get some breakfast and come back, or eat the left over pizza in the breakroom fridge. There is a lot left"
Us: "Um...sorry...we're going home."
VP-IS: "WHAT!!...OK...fine. I'll schedule the meeting for 12"
Us: "No...we're going home. We'll see you tomorrow."

I seriously cannot stress how important it is to build good reliable tests. Especially regression testing.

I am crying inside over the amount of time I've lost in my integration hell.

Seriously stupid shit that should have been tested but never did because I was too fucking lazy. Don't be me. Don't put yourself in the hell I'm in. Be better.

Two data pipelines, right before integration testing :)

What's the worst part about testing React components? Using the equivalent of fucking stone tools to do your component integration tests! We got errors with no context and errors with no stack trace, just spewing out bullshit! A sample:

The classic "Can't access .root on unmounted test renderer"

The unforgettable and ALWAYS visible "Warning: An update to YourShittyComponent inside a test was not wrapped in act(...)."

We do love it!