Magic features work before they're written!
-
From: Project Manager
To: Random list of people including devs and management chainHey - I've just tried to use
$FEATUREon firmware version 6.3 using$COMMS_METHOD_2.$FEATUREseems to work on 6.3 using$COMMS_METHOD_1and was wondering what I need to do to get this working...From: Me
To: Project Manager
CC: Same random list of people$FEATUREis totally unrelated to whichever comms method you're using - they're totally orthogonal. Comms aren't even required for$FEATURE.Furthermore,
$FEATUREwasn't introduced into the firmware until version 8.1, and certainly isn't present in 6.3Subtext: You've fucked up your testing somehow - stop blaming the devs, and stop CCing the management chain trying to make us look bad. It's backfired.
-
Subtext: You've fucked up your testing somehow - stop blaming the devs, and stop CCing the management chain trying to make us look bad. It's backfired.
I take it this is that kind of manager.
Please keep us in the loop re: fallout.
-
I take it this is that kind of manager.
No - it's more of a cover his ass type email. Which in this instance had the opposite effect...
-
No - it's more of a cover his ass type email. Which in this instance had the opposite effect...
You're saying he basically mooned all the devs and management? How rude.
I fucked up and you've all gotta fix it. Here are my butt cheeks.
Ok, so maybe not that kind of email either.
-
You're saying he basically mooned all the devs and management? How rude.
Just in case you seriously don't know the idiom:
-
Just in case you seriously don't know the idiom:
I do, but wordplay is too good to pass up. I didn't know I could use CYA as an acronym.
I guess mooning is when you're so senior that you CBA to CYA.
-
-
Once upon a time, I was making VBA macro that helps the merchandisers calculate the material they'll need to produce some goods.
Before the macro goes live to everyone inside the company, some of the merchandisers are appointed to help checking the formulas with past data to ensure it get right.
After a few iterations on cases that my code don't handle, one of the merchandisers send in data related to a past order can circled a number that has large discrepancy when compared with my computed result. After drill in the data, I found that one of the "parts" is ten folds larger than the value that should be.
Don't want to get the helpful merchandiser into trouble, my reply is to attempt to downplay the issue by saying if you enter the number of goods required 10 times the original number, the result calculated would have been correct and hoped she get the idea.
Then another merchandiser who this chain is CC-ed to step-in to say that the number of goods to be ordered should not be changed as a fix to the discrepancy. This leaves me no choice but to explain the issue is because the parts required per order for this item is incorrect.
One month later, the first said merchandiser leaves the company and I'm still feeling sorry for her.
-
#Update.
Project Manager is still insisting that
$FEATUREworks on 6.3.With an iOS client.
And other clients? Clue, I have none. He doesn't elucidate.
I very much suspect it doesn't - my suspicion is that iThings are doing something they really shouldn't and are hitting the parts of the firmware that are present in 6.3. To be confirmed however.
Oh - and the upstream connectivity between
$COMMS_METHOD_1and$COMMS_METHOD_2? I naïvely assumed that the upstream servers were the same in both cases. The firmware is talking to totally different servers (in order to switch the method) Which may, or may not, be configured similarly.
-
Define automagically .
-
After a few iterations on cases that my code don't handle, one of the merchandisers send in data related to a past order can circled a number that has large discrepancy when compared with my computed result. After drill in the data, I found that one of the "parts" is ten folds larger than the value that should be.
Don't want to get the helpful merchandiser into trouble, my reply is to attempt to downplay the issue by saying if you enter the number of goods required 10 times the original number, the result calculated would have been correct and hoped she get the idea.
Then another merchandiser who this chain is CC-ed to step-in to say that the number of goods to be ordered should not be changed as a fix to the discrepancy. This leaves me no choice but to explain the issue is because the parts required per order for this item is incorrect.
Could you re-explain this, please? I can tell something went wrong, I just can't tell the direction it went wrong in. Was the macro calculating too low a value for this part, or did the order you were comparing the macro to have 10 times too many of this part? (Or something else?)
-
It's data entry error that someone mistyped the amount of one parts needed to make one model of goods... in ten folds of the actual needed number.
This somehow had gone unnoticed originally, but when they use past data to check my calculation, the problematic data become quite visible. While this parts was in small quantity for each piece of goods, it is quite expensive, someone have to take the responsibility for this.
I was willing to play low profile for this by plainly say the ordered quantity is made 10 folds too, the number for this field will be okay, and hope to let it sneak past without raising management's attention (it sounds as if that's one of the many "data entry" problem previously pointed out). But one other merchandiser, don't know whether she had bad relationship with the original one or not, or maybe just try to point to every possible bug to resist using the new form, jumped in and said it's not acceptable, and make me have to explain the actualy nature of "the bug", and in the end the management choose to fire the original merchandiser because of this.
That's the end of story.
-
Aha, thanks. Now I understand.
Cover your ass - Wikipedia
