In this specific case (I have never encountered a proposal quite this bad), the correct answer is probably "Give me the proof of concept code and about ten minutes, and I'll give you a version that works despite the patch." You're right about that. "No" is likely to bog down the discussion with "but Bob says it will work", and it's better to skip to the end.

I'm envisioning more of a middle-ground case, where the code is still obviously wrong but it's harder to cleanly demonstrate why.

Sometimes you need an interim solution. A decent organization will be able to manage them by replacing them with actual resolution.

Cisco has a bad track record in that regard and software in general.

My employer has reached a settlement with Cisco after buying their "firepower" solution which has been plagued with basic software and usability bugs.

Ten minutes? How long does it take to type a user agent string into the curl command line?

In my case, a user agent string pretending to be Firefox is already part of my .curlrc, so it's no time at all, just grab the PoC code and fire away. (I've got commented out user-agent lines for a bunch of other browsers that I can uncomment as the need or mood strikes me.)

I'm basically assuming five minutes to read the script, negligible time to change it, and another five to make sure it worked.

You must live in a very nice, ideal world, where simply saying "no, that's not the right way to do it" will convince managers to ignore the pressures placed on them to, at times, value speed over correctness.

What they are saying is that this isn't just "the wrong way to do it". It doesn't actually fix the problem it's supposed to fix, therefore it's actually wrong to say it's a functioning patch.

Of course, but their boss doesn’t know that (or care about it), he just wants to see the fixed bug graph line approach the total bug graphline.

It’ll be totally explainable as engineer failure if something somehow doesn’t work.

Apparently I do? Not sure what you want to hear here, but management does listen to me and my engineering peers. Sometimes things are a bit gray and fuzzy, but in this case here where they definitely are not, I am absolutely certain that there would be no overriding of our arguments.

That's awesome, actually. For me, it's not as bad as Cisco seems, but there are definitely times I get overruled and have to take shortcuts that I'm not always comfortable taking.

Indeed, and what's worse is that many managers[1] will stop listening after "Yes, ...".

[1] The incompetent ones, of which there are many.