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!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.