Just for fun, there is a comedy sketch on youtube about a common-sense engineer getting beaten up in a corporate-management-moron meeting. Go to youtube and search for "The Expert" (short comedy sketch). I think most of us have been in similar situations.
I use to have a programming job where I maintained/upgraded an embedded program that the original programmer did what was correct rather than do what the boss and sales wanted. I don't know why the programmer would do this but the boss and sales would randomly walk in and quickly look at the screen and start suggesting new features or making programming suggestions (like you are using too many comments and semicolons ;-)). The original program worked great but it did not follow their manual precisely in some areas (one wonders why none of the customers or other in the company saw this?). The last programmer's joked it took up to 80 KLOCs to cut a piece of silicon and he could do it better in a few hundred lines. Well I made the mistake of mentioning these divergent areas during a manual rewrite and suggested we should make the new manual match how the program really functioned. Boy, did fertilizer impact the rotary air device. I was grilled on what I changed and everything was correct before. Even when I showed the original program was not following their manual, it was still my fault. Did I mention I use to have a programming job?
Many a time have I dealt with a methodology I call "Management by Magazine Article".
Once, a manager insisted that one member of my team rewrite three lines of code into one. The argument being that one line of code is easier to maintain than three.
The program used three move statements to construct a string (two pieces of text and a terminating 0) and the manager did not understand that technique and when explained to her, still insisted that it be written using sprintf (string print function).
The compiler would have created three MOV instructions for the three C statements. Very small, very fast. The sprintf would be interpretive and if the function library had not already been in memory, would have added K's of code to the size of the program.
So standing on the dictum she had read in a magazine article, the code went from small and fast to big and slow.
I have too many examples from her and other managers I've had to work for to list here, but it could make a book.
Not to pick on her, aside from her being at the top of my idiots list, she used to have truism that bugs in your code were like roaches, if you found one, there were ten more. but when confronted with a compiler error, she could not accept it. We reminded her of her oft stated truism, but she said that was for a program, not a compiler. We were unable to convince her that compilers were programs.
I were in a simila situation: the porting of field proven code for a Z80 processor (8 bit - little endian) to another microcontroller (16 bit - big endian).
After recompilation with the minimum of adaptions (because the code was well tested over many years) the code ran but appeared a lot of bugs and crashes that were invisible before (or well, they were there but they weren't triggered).
Only after the debugging of all buffer overflows, stack corruptions, etc.. the firmware worked again.
My favorite errant manager story is from when I worked at a small company on innovative heldheld test instruments. The manager, also being the owner of the startup company, enforced an unwritten policy that nothing made it into production unless it was his idea. I came up with an idea which improved the performance of a measuring circuit, required less PCB real estate, was cheaper to implement, and was generally less complex. As I demonstrated the circuit to the manager along with one benefit, I was advised the improvement was too minimal to implement. I noted an additional benefit, one at a time, only to be struck down each time. When I explained the simplicity of the new cicruit compared to the existing, the mananger said, and I quote, "we are not always looking for the least complex solution". Oy!
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.