Change the software, but don't let anyone know we changed it



  • This is basically how a conversation with a manager went today:

    "Make these changes to the software, but don't let anyone know we've made the changes, just change and upload"
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"
    "Absolutely not. It must be identical to the old version, apart from these changes"
    "and the version number?"
    "The version number must remain the same. Do not change it. Same goes for file size, date and everything else not covered by these changes."
    "So how would we know if the vendor is using the old code or the new code?"
    "You can test for the existence of one of these changes"

    So, we need to make the changes, being careful we don't change the size of the resulting file, and then remote into vendor servers to secretly upload the new code. We can only test locally, otherwise it would be "suspicious", and the only way of confirming success is to check that the changes exist. 

    I suppose I can at least say my job is challenging :-)


  • 🚽 Regular

    Well, duh... by updating the software, you are basically telling the vendor that your previous version was imperfect, inadequette, and buggy. If your customers ever found that out, they'll promptly abandon your software, and go to some competitor that hasn't updated since 2000.

    I just love how secretive this update is, to the point where he thinks someone is keeping track of the friggen file size and will out you guys if he notices a change.

    How do you plan on releasing this update? Are you going to secretly download and install it on his computer without his knowledge? If he finds that out then you can bet you'll get in trouble.



  • @Mole said:

    This is basically how a conversation with a manager went today:

    "Make these changes to the software, but don't let anyone know we've made the changes, just change and upload"
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"
    "Absolutely not. It must be identical to the old version, apart from these changes"
    "and the version number?"
    "The version number must remain the same. Do not change it. Same goes for file size, date and everything else not covered by these changes."
    "So how would we know if the vendor is using the old code or the new code?"
    "You can test for the existence of one of these changes"

    So, we need to make the changes, being careful we don't change the size of the resulting file, and then remote into vendor servers to secretly upload the new code. We can only test locally, otherwise it would be "suspicious", and the only way of confirming success is to check that the changes exist. 

    I suppose I can at least say my job is challenging :-)

    Perhaps you should explain the concepts of checksums and/or file hashes to your boss. While you're at it, explain the consequences of dishonesty to him as well.


  • ♿ (Parody)

    @Mole said:

    "So, let me get this right, we can't let the vendor know we've actually changed anything?"

    This is perhaps the most intriguing part of this WTF. What are you guys trying to do, reduce the price you pay for something?



  • @The_Assimilator said:

    @Mole said:

    This is basically how a conversation with a manager went today:

    "Make these changes to the software, but don't let anyone know we've made the changes, just change and upload"
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"
    "Absolutely not. It must be identical to the old version, apart from these changes"
    "and the version number?"
    "The version number must remain the same. Do not change it. Same goes for file size, date and everything else not covered by these changes."
    "So how would we know if the vendor is using the old code or the new code?"
    "You can test for the existence of one of these changes"

    So, we need to make the changes, being careful we don't change the size of the resulting file, and then remote into vendor servers to secretly upload the new code. We can only test locally, otherwise it would be "suspicious", and the only way of confirming success is to check that the changes exist. 

    I suppose I can at least say my job is challenging :-)

    Perhaps you should explain the concepts of checksums and/or file hashes to your boss. While you're at it, explain the consequences of dishonesty to him as well.

    And after you do that, let us know about his reaction.



  • Woudn't it be a better idea to tell the client about it so that you can charge money for it?



  • I'd refuse to do it, personally. It just rubs me the wrong way.



  • @Mole said:

    Make these changes to the software
    What are these changes exactly? And why the secrecy? Surely you asked why noone can know, right?



  • @DOA said:

    @Mole said:

    Make these changes to the software
    What are these changes exactly? And why the secrecy? Surely you asked why noone can know, right?

    Probably adding a backdoor, or a Superman III-esque "subtly slip money into an offshore account" function. Ask for a cut!



  • @blakeyrat said:

    @DOA said:

    @Mole said:

    Make these changes to the software
    What are these changes exactly? And why the secrecy? Surely you asked why noone can know, right?

    Probably adding a backdoor, or a Superman III-esque "subtly slip money into an offshore account" function. Ask for a cut!

     

    The secrecy is because the PHB understands all too well that the vendor/user will respond to any suggestion of a software change with a shriek of "O NOES! Now we must repeat the four-month acceptance test, and you foul developer are responsible for this impact to our schedule and resources!"

     



  • I'd tell him the proposed change increases the file size, and there is no way to remove "bits" from anywhere else.  This sounds completely plausible and it is probably true.


  • 🚽 Regular

    @frits said:

    I'd tell him the proposed change increases the file size, and there is no way to remove "bits" from anywhere else.  This sounds completely plausible and it is probably true.

    Then just borrow some bits from Minesweeper! Nobody should be playing that on company time anyway. How can you call yourself a developer?



  •  You should go work for someone else.  In a business relationship, honesty and openness are essential.  Think how much better it is when the customer finds out that the software he piurchased had a bug; but that your company is pro-actively testing the software and has developed a fix for it, even before the customer has run into the issue.  

    And if the company had run into the issue, they at least can decide if any important business decisions were affected by the bug, and they will have a chance to adjust those decisions or decide that the bug did not have an effect.

    Compare that to the inevitable case where the customer discovers that you slipped in a bug fix.  It's bad enough that you were -- on their computer -- without permission -- without telling them -- without any indication of why you were on their computer.  The worst part is that the customer does not know what the bug was.  Maybe some important business decisions were based on faulty results; or maybe they weren't.  But the customer won't be able to tell.

    I'd rather know that there was an issue and exactly what it was, than just know that some unknown issue was fixed.

    AND if your boss can treat his customers this way, consider that he is likely treating you the same way.  I'd check my 401K account right now, if I were you.


  • Discourse touched me in a no-no place

    @dogbrags said:

    Compare that to the inevitable case where the customer discovers that you slipped in another bug fix.
    IME this is what is more likely to happen.



  • I'd still like to know what the changes are and why the "vendor" won't notice them?

    Of course I also wonder how the boss will know you've done it.

    "All done, boss."

    "So fast"

    "Sure, check their server. The file size and date haven't changed, have they?"



  •  @DOA said:

    @Mole said:

    Make these changes to the software
    What are these changes exactly? And why the secrecy? Surely you asked why noone can know, right?

    Its just a few bug fixes. The idea is that if the vendor is informed then there will be meetings about what the bugs are, how they occur, steps to reproduce, why they were not picked up in testing, how we plan to fix the bugs, ETA of patch, testing the patch, confirming no other part of the system was affected by the patch, etc. The changes amount to less than an hours worth of work; if we go through official channels it will be about a months worth of work, most of which is paperwork.

    I can see exactly why they don't want the later the happen (I prefer this way too, less work for me), but it still smells of WTF...

     



  • @Mole said:

    @DOA said:
    @Mole said:
    Make these changes to the software
    What are these changes exactly? And why the secrecy? Surely you asked why noone can know, right?
    Its just a few bug fixes. The idea is that if the vendor is informed then there will be meetings about what the bugs are, how they occur, steps to reproduce, why they were not picked up in testing, how we plan to fix the bugs, ETA of patch, testing the patch, confirming no other part of the system was affected by the patch, etc. The changes amount to less than an hours worth of work; if we go through official channels it will be about a months worth of work, most of which is paperwork.

    I can see exactly why they don't want the later the happen (I prefer this way too, less work for me), but it still smells of WTF...

    I wonder what their reaction will be to you, without their consent, logging in and uploading a new version on *their* servers...  I would rather have a friend let me know he needs some cash rather than finding him searching through my wallet.



  •  Just think of it as an "Automatic update". Lots of software can update itself without your knowledge (although unlikely on Windows vista and above unless you disabled UAC) same as when Windows reboots your PC for you every patch Tuesday. 



  •  I've tried to suggest similar before.  Big High Profile Customer Inc.has decided upon version 4.6.8.3 of our software as the platform they will deploy on, but they found a few bugs during their testing (all of which were found by our own QA team and fixed in 4.7), and they want them fixed on their environment.  But they can't take 4.7 because any upgrade requires them to do a big regression test.  I don't know why giving them a patch doesn't force a regression test.  Especially given that they reported all but a handful of the bugs fixed between 4.6.8.3 and 4.7, scept for a few UI changes to a feature they don't even use.

    So, there was joking talk of just deploying 4.7 to them and manually overwriting the file that holds the version number.  Everybody else in the room was joking at least.  I was serious.


  • Discourse touched me in a no-no place

    @Mole said:

    Its just a few bug fixes. The idea is that if the vendor is informed then there
    will be meetings about what the bugs are, how they occur, steps to reproduce,
    why they were not picked up in testing, how we plan to fix the bugs, ETA of
    patch, testing the patch, confirming no other part of the system was affected by
    the patch, etc.
    I'm probably not alone in failing to see the WTF here...
    @Mole said:
    The changes amount to less than an hours worth of work;
    And that's what sends my bollocks detector off, and prompted my earlier comment of 'it'll introduce more bugs.'



    I've been bitten by the 'only a little bit of work' turning into 'oh fuck - roll it back.'@Mole said:
    most of which is paperwork.

    If it's a live system, there's a reason for the paperwork.



  • @Mole said:

     @DOA said:

    @Mole said:

    Make these changes to the software
    What are these changes exactly? And why the secrecy? Surely you asked why noone can know, right?

    Its just a few bug fixes. The idea is that if the vendor is informed then there will be meetings about what the bugs are, how they occur, steps to reproduce, why they were not picked up in testing, how we plan to fix the bugs, ETA of patch, testing the patch, confirming no other part of the system was affected by the patch, etc. The changes amount to less than an hours worth of work; if we go through official channels it will be about a months worth of work, most of which is paperwork.

    I can see exactly why they don't want the later the happen (I prefer this way too, less work for me), but it still smells of WTF...

     

    I have a theory that states that the more stupid the processes people have to follow, the more people will naturally shift from the lawful side to the chaotic side of the alignment chart.

    Hence the OP's boss giving him such a sidequest.


  • Discourse touched me in a no-no place

    @vt_mruhlin said:

    I don't know why giving them a patch doesn't force a regression test
    Because they didn't follow Mozilla's recent example of versioning?



    4.bollocks.wank is broken, we've replaced it with 4.bollocks.piss. No regression testing needed



    [someone has the bright idea at FFHQ to promote every number in the version...]



    5.fuck is the new version. "Oh shit - they've incremented the major number - we need testing!!!one!@"



  • @PJH said:

    @vt_mruhlin said:
    I don't know why giving them a patch doesn't force a regression test
    Because they didn't follow Mozilla's recent example of versioning?

    4.bollocks.wank is broken, we've replaced it with 4.bollocks.piss. No regression testing needed

    [someone has the bright idea at FFHQ to promote every number in the version...]

    5.fuck is the new version. "Oh shit - they've incremented the major number - we need testing!!!one!@"
    I feel like a cripple without my gestures. And it hurts.



  • @boomzilla said:

    @Mole said:
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"

    This is perhaps the most intriguing part of this WTF. What are you guys trying to do, reduce the price you pay for something?

    How is it that nobody else is talking about this part of the post?

    In other news, my employer has fired both customers and vendors from pulling crap like this.  (Hint: we know how to do cksum, md5sum, shasum, and several others.  We don't apparently know how to optimize our tripwire config by simply trusting one.  We also know how to use intrusion detection systems and automated log monitors, even on reverse proxy logs, and there's a few of us who even know how to read the vendor's code to find their code injection points...)

    The sad thing is, I'm not sure we ever managed to *tell* any customers or vendors that they were fired for pulling crap like this.  Rather, we simply indicate things haven't worked out or we've found a better vendor or some crap like that.  Admittedly, I've only been involved with vendor attempts - according to rumor, we're much less polite about it when a customer does it.

    (And, yes, while I am aware of instances where various of our customers tried pulling this sort of stunt, I still don't see it as really comprehensible, unless y'all have confused relationships such that they're not really just a vendor.)



  • @tgape said:

    In other news, my employer has fired both customers and vendors from pulling crap like this.

    How do you fire customers?

     


  • Discourse touched me in a no-no place

    @tgape said:

    @boomzilla said:
    @Mole said:
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"

    This is perhaps the most intriguing part of this WTF. What are you guys trying to do, reduce the price you pay for something?

    How is it that nobody else is talking about this part of the post?

    Because most of us are assuming ESL/typos are in play and it's not relevant? The OP certainly hasn't responded on it.



  • [quote user="Renan "C#" Sousa"]

    I have a theory that states that the more stupid the processes people have to follow, the more people will naturally shift from the lawful side to the chaotic side of the alignment chart.

    Hence the OP's boss giving him such a sidequest.

    [/quote]

    I have the same theory, too, mostly because I know I follow it. I've been trying to explain it to one of my architect-as-a-verb coworkers who wants to impose stupid restrictions and branding on our APIs for the sake of "standardizing". (But I'm pretty sure the truth of the matter is that she just wants to show our users who's boss. Such a dick.) She's of the opinion that we get to dictate what how our internal customers design their applications when they use our interfaces, and that all the mandates she's throwing at them won't make them just work around us. Of course, they already ARE working around us, and if I were them, I would, too. But it's all about enterprise policy and politics and power struggles with her! Seriously, who adds redundant and useless but required parameters in an API just to make the client work? Of course, she also likes to dish out work to everyone on the team whenever she gets in a bad mood, so maybe it's not so surprising.



  • @Mole said:

    This is basically how a conversation with a manager went today:

    "Make these changes to the software, but don't let anyone know we've made the changes, just change and upload"
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"
    "Absolutely not. It must be identical to the old version, apart from these changes"
    "and the version number?"
    "The version number must remain the same. Do not change it. Same goes for file size, date and everything else not covered by these changes."
    "So how would we know if the vendor is using the old code or the new code?"
    "You can test for the existence of one of these changes"

    So, we need to make the changes, being careful we don't change the size of the resulting file, and then remote into vendor servers to secretly upload the new code. We can only test locally, otherwise it would be "suspicious", and the only way of confirming success is to check that the changes exist. 

    I suppose I can at least say my job is challenging :-)




    "We no longer have access to production systems"

    "So what do we do?"

    "We go through the ventilation shafts"



    (Mission Impossible Theme)




  • @Mole said:

    This is basically how a conversation with a manager went today:

    "Make these changes to the software, but don't let anyone know we've made the changes, just change and upload"
    "So, let me get this right, we can't let the vendor know we've actually changed anything?"
    "Absolutely not. It must be identical to the old version, apart from these changes"
    "and the version number?"
    "The version number must remain the same. Do not change it. Same goes for file size, date and everything else not covered by these changes."
    "So how would we know if the vendor is using the old code or the new code?"
    "You can test for the existence of one of these changes"

    So, we need to make the changes, being careful we don't change the size of the resulting file, and then remote into vendor servers to secretly upload the new code. We can only test locally, otherwise it would be "suspicious", and the only way of confirming success is to check that the changes exist. 

    I suppose I can at least say my job is challenging :-)

     

     

    Maybe the best way is to not make changes and let him know that they have been done.  After all, if they never know, then he will never know.  If the changes ARE important slip them into the next formal release and put it in some vague reference in the  documentation that the client will read.  When/If  they ask about the changes, just get the boss to explain why they are made and tell him that you forgot about this reference in the documentation and add something along the line of "good thing this went through relatively calmly because you hate all this creeping around shit and do not want to do it again"

     



  • @Mole said:

    Its just a few bug fixes. The idea is that if the vendor is informed then there will be meetings about what the bugs are, how they occur, steps to reproduce, why they were not picked up in testing, how we plan to fix the bugs, ETA of patch, testing the patch, confirming no other part of the system was affected by the patch, etc. The changes amount to less than an hours worth of work; if we go through official channels it will be about a months worth of work, most of which is paperwork.

    I can see exactly why they don't want the later the happen (I prefer this way too, less work for me), but it still smells of WTF...

     But you *must* alread have the full documentation about the bugs, the test cases you used to reproduce them, the remediations made to your testing suite to ensure that furute bugs do not get through, et. al.

    Since you already ivested all of that time in having a sold process in place, why not just present the information to the vendor....

     (You do already have all of that documentation internally...dont you?)



  • @joeyadams said:

    @tgape said:

    In other news, my employer has fired both customers and vendors from pulling crap like this.

    How do you fire customers?

     

    There are at least three ways:

    • Tell the customer you are no longer interested in their business.  You may optionally give them a reason.
    • Intentionally provide poor service.  If you don't have fixed prices, this can also be combined with jacking up the price.  Do this sufficiently, and they'll stop purchasing what you're selling.
    • Sue them.  Few customers will continue purchasing items or services from a company that is taking them to court...  This method may be combined with either of the other two.

    Actually, there's another, more literal method, but it generally makes it difficult to retain other customers, and has another of other potential unpleasant side effects.  The methods I actually listed above are all legal in at least *some* circumstances.  I wouldn't recommend trying to fire a customer if at least two out of the three aren't legal in that particular circumstance.

    Edit: BTW, I am not a lawyer.  I don't play one on TV or online.  I don't even play one in Papers and Paychecks.


Log in to reply