![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Okay, other than the fact that your three attempts over two years at getting this system live FAILED like a big flaily faily thing.
Look, you aren't using the live system. No, you're not. It failed, remember? And you had to back everything out and revert back to the old system because you screwed the pooch. And so the Australian office has had to not only get our stuff working, but yours as well - and we've even done it on time! We're set for a go-live in under 6 months and while I have serious doubts about the degree of testing needed to really make sure the system is solid/stable/robust/idiot-proof, I can't deny that, as long as users do exactly what they should be doing and don't make mistakes (AHAHAHAHAHAHAHAHAHA... *ahem*), the system works.
But that's a tester problem, not a tech problem.
The fact remains: you aren't using the live system anyway. And the changes we're asking for? We're asking for in the Quality Assurance system - where we're doing testing for that go-live thingy that's happening in four months.
So when we indicate that we need successful file transfers in QA retained for a couple of weeks (and please note: the standard system implementation keeps successful files for 8 days, while you delete them in 1 day) because we're in the middle of testing and would like to look at things that you've deleted for the purpose of working out system load, messages volume, and timing, your response should not be "why, if they are successful, would we need to keep them?"
You're obviously not a programmer.
Sometimes the best way to determine why an error has happened in an unsuccessful procedure is to look at a successful procedure of the same type and determine what has changed. In this specific instance, if, say, two messages had been unsuccessful, we would have no successful records visible to use as a benchmark for comparison. Because you deleted them.
This is just one more cherry on the icing of your inability to cede any kind of control over to the Australian office. Who are getting the job done. That job which you failed to do two years ago. And the year before that. And the year before that.
Get a grip on your inadequacies, and let us do our job. (We're better at it than you are.)
no love,
a very annoyed programmer.
Look, you aren't using the live system. No, you're not. It failed, remember? And you had to back everything out and revert back to the old system because you screwed the pooch. And so the Australian office has had to not only get our stuff working, but yours as well - and we've even done it on time! We're set for a go-live in under 6 months and while I have serious doubts about the degree of testing needed to really make sure the system is solid/stable/robust/idiot-proof, I can't deny that, as long as users do exactly what they should be doing and don't make mistakes (AHAHAHAHAHAHAHAHAHA... *ahem*), the system works.
But that's a tester problem, not a tech problem.
The fact remains: you aren't using the live system anyway. And the changes we're asking for? We're asking for in the Quality Assurance system - where we're doing testing for that go-live thingy that's happening in four months.
So when we indicate that we need successful file transfers in QA retained for a couple of weeks (and please note: the standard system implementation keeps successful files for 8 days, while you delete them in 1 day) because we're in the middle of testing and would like to look at things that you've deleted for the purpose of working out system load, messages volume, and timing, your response should not be "why, if they are successful, would we need to keep them?"
You're obviously not a programmer.
Sometimes the best way to determine why an error has happened in an unsuccessful procedure is to look at a successful procedure of the same type and determine what has changed. In this specific instance, if, say, two messages had been unsuccessful, we would have no successful records visible to use as a benchmark for comparison. Because you deleted them.
This is just one more cherry on the icing of your inability to cede any kind of control over to the Australian office. Who are getting the job done. That job which you failed to do two years ago. And the year before that. And the year before that.
Get a grip on your inadequacies, and let us do our job. (We're better at it than you are.)
no love,
a very annoyed programmer.