Knowledge can be a terrible thing.
In my case, helping a newbie with circuit design found a beginner's mistake which causes a circuit to run slow. I used a technique which I learned from They Write the Right Stuff in which NASA improves hardware and software quality by looking for similar classes of bugs elsewhere. I wish that I hadn't looked. The newbie had copied a flawed template which has been used by more than 50 parties over 15 years. The flawed design has been promoted by an expert in the field and is used by other noted experts. The most likely explanation is that the design was devised when the expert was less knowledgeable. It has subsequently been propagated until it has become an unchallenged article of faith. An alternative explanation is that the design is deliberately flawed to detect plagiarism.
The published design works. However, I am very certain that moving one or two wires would make it work about 10% faster. This has very probably caused projects to fail unnecessarily, cause people to abandon projects or implement designs which have reduced throughput. In the worse case, a system can be fixed by making it operate at half speed. This leads to a professional quandary. It would be easiest to not mention the flaw. However, if I silently apply the fix to my own work, this design variation may be noticed sooner or later. Therefore, *completely* ignoring the problem willfully undermines the efficiency and reliability of my own work. Whereas, reporting the flaw publicly may undermine the expert or incur a "shoot the messenger" scenario. In either case, this may discourage people from using the flawed or fixed design and may reduce interoperability.
Perhaps a way out of this problem would be privately and jokingly mention that I found the deliberate mistake? The expert is uncharacteristically touchy about uncredited use of a design which can be derived independently using the Quine-McCluskey algorithm. This leads me to consider that the inefficiency is deliberate. That would make it the Quine-McCluskey-Dunning-Kruger algorithm.
Have you been in a similar situation? What did you do and how did it work out?
(Score: 2, Funny) by Anonymous Coward on Friday February 05 2021, @01:20AM
How far along would human progress be if not for bad intent?
(Score: 3, Insightful) by Anonymous Coward on Friday February 05 2021, @01:21AM (4 children)
It could be a fan-out limit which might not even apply to newer hardware.
It could be a physical space issue.
It could be an optimization for an older production process.
It could be a work-around for limits or bugs in older design software.
(Score: 1, Insightful) by Anonymous Coward on Friday February 05 2021, @01:31AM (1 child)
Exactly. WTF is this about? Summary is empty balls.
(Score: 1, Touché) by Anonymous Coward on Friday February 05 2021, @04:42AM
That only happens at your mom's house.
(Score: 3, Insightful) by rleigh on Saturday February 06 2021, @01:29PM
Depending upon the domain, there might also be safety and regulatory concerns. A 10% speed increase is irrelevant if you have to re-test and re-validate everything from scratch. That can cost millions and take several man-years worth of combined effort. Changing a well-known and well-understood design also adds risks. Unless it solves an actual problem or provides a big concrete benefit, you aren't going to take that risk and cost. You already know the existing design works well, is safe under all known failure modes, and you understand every aspect of its behaviour both in isolation and as a part integrated into a wider system. Any change, even a trivial one, can have non-obvious effects upon other parts of the system, and you need to fully consider the implications and effects of the change.
That said, I work in such a field and we make changes on an ongoing basis, but everything has to be carefully evaluated and rationally justified, and painstakingly tested. If you suspect there might be a problem, you have to take time to fully understand and characterise it, and the consequences of changing it, before even thinking about making a production change.
(Score: 2) by VLM on Saturday February 06 2021, @08:33PM
OP needs to define faster. Look at the history of sort algos, theres still zillions and people implementing their own because nobody can define faster.
For any algo, not just sorting and not just whatever OP is trying to do, theres more to speed than just average. There's "mostly optimal" cases where the algo has little to do and often enough algos spend most of their time doing nothing (just add one data point, not sort an entire dataset). There's absolute worst case where maybe the system can't survive the absolute worst case being something that scales exponential with time or memory or I donno.
I mean, you pick your sort algo by seeing which algo sorts random data sets fastest. But nobody does that as an actual profit generating workload, LOL.
At least with hardware the stereotype of "I'm a gonna make it faster by eliminating this seemingly redundant circuitry" locks it up because clock skew and jitter is a thing along with race conditions. I mean "everybody" knows the input and the output of an inverter can't be the same binary value at the same time, rightie oh? Well it actually happens for some ps every time it changes state, for example. All digital hardware is fundamentally analog if you push the limits hard enough.
(Score: 4, Insightful) by Anonymous Coward on Friday February 05 2021, @01:34AM (1 child)
Is this something work-related? If so, do you have a boss or supervisor? If you do, bump the issue up to them and let them decide what, if anything, to do about it.
They get paid more than you (usually). Make 'em earn it for a damn change. Be sure that you document that you threw the issue into their lap, and document whatever response (or lack thereof) you receive. Then do whatever your boss told you to do.
Every time I had an issue like this, that could blow up beyond my own area of responsibility, I kicked it up to whoever my boss was at the time. Well, every time other than the first time I didn't, and really learned that lesson the hard way.
(Score: 0) by Anonymous Coward on Friday February 05 2021, @06:50PM
As they say, never be the highest ranking official to know the most.
(Score: 5, Insightful) by The Mighty Buzzard on Friday February 05 2021, @03:35AM (1 child)
Look, if you have a better or simply fixed design, publish it. Anonymously if you must. There is absolutely no sense using crappy design just because we've done so for a long time. Yes, it may cause a little bit of turbulence but that is far preferable to premeditated stupidity. We have more than enough of that in the world as it is, thank you very much.
My rights don't end where your fear begins.
(Score: 3, Insightful) by sjames on Friday February 05 2021, @05:47AM
Exactly. This is engineering, not a high school popularity contest. If the published solution is flawed and the new one is not, the results will speak for themselves.
(Score: 2) by RamiK on Friday February 05 2021, @04:08AM (2 children)
CC him when you send it out to the publisher.
Problem solved :D
Being more practical, just publish your design and mention during prior art that you found the expert's solution but it's inferior due to a few shortcomings such as that flaw.
compiling...
(Score: 0, Flamebait) by Anonymous Coward on Friday February 05 2021, @08:19AM (1 child)
For god's sake no. That's now what second authors are. You're confusing "by" with "about". Just reference his design, if you have to mention it at all.
And to the submitter:
It sounds like (hard to tell, the article's terribly written by some kind of passive aggressive psychopathy) the former broken design drops out of an automated process, in which case, the human once associated with it is irrelevant. You've improved on the automatically generated design that's all.
Which highlights another aspect of shitty writing - how the fuck can you not know if this implementation is the expert's or not? Why do you fuss about his reaction to improvement if t's not his design?
To be honest, The first thing you need to do is learn how to communicate with people whose reactions you care about in a mature manner. Your passive aggressive tone, and your mention of "joking" about the improvement tells me you are a complete social retard. Learn some fucking people skills.
No. I don't care about the reaction of the A/C submitter, I committed no fallacy. He needs a slap; once the slap is delivered, I just walk away.
(Score: -1, Flamebait) by Anonymous Coward on Friday February 05 2021, @08:54PM
The only way any of the bullshit makes sense is if the "expert" is now a higher up in the company, and the submitter is worried about retaliation for making him look an idiot.
(Score: 5, Interesting) by Anonymous Coward on Friday February 05 2021, @06:39AM
(parts of this have already been said by others here)
Simply put: do you have an engineering problem, or do you have a politics problem?
Engineering is a) about verifiable fact and b) about the well-considered weighing of diverse influence factors. That's your compass, use it to the max:
Is yours faster? Then don't just say so, give a reference design and show your numbers and how you obtained them. In comparison to the other design. Again with numbers and how you obtained them, in detail. Present in detail your derivation from first principles. Detail *is* important, because there may be factors involved that *you* overlooked ... be open to humility, be careful in your choice of adjectives (be extra-factual, extra-provable, and if you write 'wrong' you better be damned sure that it is under all thinkable - not probable - circumstances!). That's also the format of every well executed hard-sciences publication (read up theory, and read at least two publications, if you haven't). Yes, that's a lot of work, but if you're after "truth", that's how the endeavour works. (and *that* is the argument for politics, see below)
Actual engineering can be right vs. wrong, but usually it's about weighing of factors that are considered differently for different conditions. As was already said better by a different AC: "fastest" is not the only design criterion! Make an effort to think about this. Do present this effort in your write-up, presenting potential weighings of factors against one another. Be acceptant of the fact that things may have changed over time.
Now the political stuff, that's different. Politics is about totally different goals (yours and theirs!) and truth and verifiability are not important at all. That doesn't neccessarily mean "bad", although it often seems so, and sometimes is. But you have to realize the difference. And you also have to realize that, for an engineer, politics is really hard (just like the other way around!).
Are *your* goals also political in nature, at least in part? Be honest with yourself!
Because they are: you want to change the status quo of how "business" is done. That' political all right. "Simple to do" comes into play (for whom?), and "change established process". Be aware that "change nothing" is the personally easiest way out, by far, for many, many people - they do NOT care at all about the end result (just buy a better chip!), they get paid by they hour, they just want to be left alone. Especially by you, who says they've been doing it wrong for decades, what do you think they are, stupid or what? Then apply the same mindset to the managers of these people. *This* is the territory of actual politics. Since you're asking here, don't venture too far - humans can do that stuff, but IMVHO the required mindset mostly disqualifies us engineers.
The first thing, for an engineer in politics, is being mostly right factually, see the engineering part above. Because if you're wrong and being political about it, you're just a ********. But the second thing is about persuasion. You will probably not persuade the original author (being correct may help, but not with the author you describe) but you may persuade others (being factually, demonstrably, repeatably correct definitely does help there). And you will never persuade everybody, not even close. So don't try. And keep the original author out of it. Not "He is wrong!", because you won't cure him, and it doesn't support your point, and it's a purely political move-to-kill, and *that* makes everybody else distrust you. But rather "This is right(er), and here's how I prove it, and I think[!] we should do that instead".
Since you want to persuade, you have to publish (somehow....). If you do not publish, you will not persuade anybody, because nobody won't know nothing. Even if you "publish" only through word of mouth, you will need to a) be correct and b) present your case, so the work for good engineering outlined above is still required. Obviously, all publishing has consequences.
If you publish with your name, it will add credibility whether people know you or not - or rather: anonymous takes a credibility hit. But your name also opens you up to backlash from the author, from interested parties, from the army of incompetent Indian students who want you to do their first-grade homework on Ohms law, and from total dicks who walk around insulting people for nothing, but with exceptional force. If you go anonymous, your arguments have to stand on their own, under attack. You better prepare them for it, because after "Send" you can't reply or counter-argument anymore. Do you want to discuss and engage afterwards? Then pseudonymous publishing may be for you - the backlash will come, but at least not to your real life. If you publish well, then do not underestimate the feeback in volume, potential viciousness, OR professional goodwill and courtesy.
The advice for workplace action (different post) was good, IMNSHO. Be aware that "workplace" is never anonymous, and that workplace politics can get you into serious trouble jobwise, or even a mental hospital (I've seen it). Even if you are right. Especially if you are right. If your problem is there, my personal, risk-averse advice would be to publish anonymously in public, and hope for the best. Humanity-wise. Again: if you're nodding your head *here*, and want to change your workplace under these conditions: don't! Change jobs. At personal losses. Right the fuck now, while you still can. Fuck the public, fuck engineering, just run! And *then* publish, it might even get you another job if you do it right (stay clear of "work-for-hire" regulations in your country or contract). But don't first publish anonymously and then point to it at work going "see, I told you so". You're up against the varsity there, and it's not your league.
And then of course there's the pure politics route: persuade people to do anything knowing full well that you are wrong :-D But that's not your point, and you probably couldn't pull it off anyway ;-)
Hope that helps! Good luck.
NB:
If you do publish, and have a good technical article, hack-a-day may always be interested (and may also be read by your target audience?). Soylentnews too, as a follow-up to this? Perhaps including your decisions, reasoning and how it went? Would make a nice companion article to the purely technical stuff ...
(Score: 1, Insightful) by Anonymous Coward on Friday February 05 2021, @07:15AM
(Score: 3, Insightful) by r_a_trip on Friday February 05 2021, @01:56PM
I'm not an engineer, but I know corporate structures pretty well. Going against business as usual mostly is not a good idea carreer-wise. If it ain't broke, don't fix it as an underling without being asked.
You claim a 10% improvement in speed by altering the design minimally. Furthermore you claim disastrous consequences for projects by that 10% reduction in speed in the original design. You also claim that the less performant design has been in use for at least 15 years.
Just looking at the surface, this doesn't add up. If a gizmo is widely used and causes many project failures, there would be emphasis on improving this piece of technology or work around it completely. Either way, it wouldn't be used in its current form as an accepted implementation for over 15 years. Which causes me to think that your 10% speed improvement can't be the make or break factor over the original design.
(Score: 4, Insightful) by KritonK on Saturday February 06 2021, @12:36PM (1 child)
I was taught early on in my career to never speak poorly of something that people have been using for a long time and are comfortable with. If you have made an improvement on such a thing, there are two ways to promote it.
The wrong way: The current method of doing x is flawed.
The right way: The current way of doing x is the time-tested and reliable method y, which has been in use by the industry for 15 years. We have discovered that by making a small tweak to this method, we can gain an additional 10% in performance.
With the first approach, you will get lots of nasty stares, and maybe even make an enemy or two. With the second, you will make people eager to learn the details. By praising the current system, you praise its users for having made the right choice, and the system's designers for having made a good design. Then, by suggesting that this fine system can be further improved, you have its users hooked. If, after having adopted the new system, it becomes evident that the old system was crap, well, it wasn't you who said it, but the people who adopted your system!
(Score: 4, Interesting) by Booga1 on Saturday February 06 2021, @02:24PM
Agreed. The sugar coated version is far more likely to win people over. People get defensive over stuff they've made.
I myself have found work I've done changed or replaced and thought, "Why did they change that? It worked! It was fine!" Then I'd take a closer look and see that the new code or procedure was actually better. But, until I have a moment to review the change and process it, the initial reaction is almost "painful," even if only for a moment.
If I had someone straight up telling me that my stuff was flawed and "deliberately bad," I would most likely be angry. Any attempt to convince me to listen to them after that would be a hard hill to climb. I'd much rather someone approach me and say "I think I've found a better way to do this, what do you think?" At the very least ask me why I did something that doesn't make sense. There's usually a good reason for it.
(Score: 3, Insightful) by Rupert Pupnick on Saturday February 06 2021, @07:35PM
The main problem you have is too late to solve: you don't have a spec or a clear design requirement. Nevermind about some 10% parameter improvement. Either the design meets the performance spec, or it doesn't. In this regard, there can be no disagreement among staff.
Even without a spec, an improvement is still an improvement. Let the measurement data tell the story. There's no need to think of the lesser performing implementation as a mistake. If the organization you work in cannot adopt that approach to design engineering, you need to find another organization.