Spaghetti Code & Meatball Managers

How to deal with a meatball of a manager who issues an edict that makes no earthly sense? Ignore it.

There are valuable contributions that management can make to the design process. Let me get back to you on that later.

Every engineer at some point in his or her career has heard a martinet of a manager say something along the lines of: "I'm the boss, so I get two votes"; or "It's not a democracy around here." Not exactly the best way to rally the troops.

Here is my advice on dealing with a meatball of a manager who issues an edict that makes no earthly sense: Ignore it.

To wit, earlier in my career I was hired as an ARM specialist at a midsized company. My job was to design a new system using a 32-bit platform. The company's legacy, 8051-based products were based on code that was ghastly, having the appearance of generations of legacy maintainers.

The concept of spaghetti code had just been elevated to new heights.

All variables were Globals, declared in a single header file. Scarce comments showed many dated from 10 years back.

Yet this particular manager issued the following instructions: "This code is field-proven over more than 15 years. It is completely bug-free and is the result of 15 years of development. Do not change it! Re-compile this C program to the new processor and keep it exactly the same."

In the first week alone I discovered at least three serious bugs and learned that units in the field suffered from the same defects. At that point I stopped following the no-change order and simply enumerated all the vulnerabilities and most severe software design flaws in that product line.

I ended up designing the new system from scratch. The product served for more than 10 million hours in the field over the next six years with zero firmware crashes.

— Jonny Doin is now CEO of GridVortex Systems. He has over 25 years experience working with embedded systems R&D and hardware/firmware design. He has worked on medical, broadcast video, industrial, and energy applications and founded GridVortex in 2012 to design and deploy IoT intelligent networks for large-area urban projects and embedded micro-clouds.

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!

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?

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 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.

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.