Crazy things people have said to me
Aug 11th 2020
Here are some crazy coding and embedded development things people have said to me.
"It is one line of code, therefore it is atomic"
This from a developer who was talking about a line of C code. Ironically the funny part was he was a senior developer working on a compiler. Yes they did go out of business...
"Listen we need to approve this schedule now and then we will slip it later"
This was from project manager who was trying to get company to fund a project. The company said they would if it could be done in 6 months. The product required FCC type approval which at the time had to be scheduled 6 months in advance. The company did fund project and canceled it later.
"Yes the schedule is tight and we are behind, but the schedule was unrealistic anyway so we don't need fast turn."
This was from manger when asked if I needed to order PCBs with faster turn around time for an extra couple hundred dollars to save a week of time.
"Lets order boards after Christmas break"
This is what project manager did on a tight scheduled project as he did not want to do the paper work. This ended up causing a 3 week delay in the schedule costing the company over $315k in lost revenue.
"Lets make that decision on Monday, it's 4pm on a Friday."
This was manager delaying making a decision on critical item to a project which was already a month behind schedule.
"Yes I understand that the code has bugs, I have not seen the bugs so don't change the code"
This was a manager telling me to reuse code from a previous project and keep the bugs found during code reveiw because he had not experienced the bugs personally.
"I don't appreciate you telling me that our products could cause fires and recommending stop shipment while I was on vacation."
This was a manager who was upset that their product could cause fires and kill people, not upset that the product had problems, but rather that he was informed while he was on vacation.
"You have to use global variables, how else can functions share values?"
This was from an embedded programmer with 20 years of experience justifying us of global variables in C.
"OK for this project we have to use all the new features in C++17."
This was a manager telling the embedded firmware team that they must use all the new features in C++17 for the product, because it was cool.
"New is not malloc, it is OK to use on embedded systems, C++ handles it different so it does not cause memory fragmentation."
This was the same manager justifying using C++'s new operator in embedded designs.
"OK you have proven water can get onto the circuit board, but you have not proved this is a problem."
This was a manager telling that I needed to prove that water getting onto an non conformal coated circuit board would cause a problem with product. Yes he had an electrical engineering degree.
"OK you have proven that the line calibration is wrong, but it is not our job to fix it."
My manager told me this, the company was shipping 5,000 units a day when I found the calibration was broken. Took 4 months for them to decided who should fix it. In the mean time they continued to ship products which they latter had to recall.
"Quality is number returned units divided by number of shipped units."
The company I worked for used this quality metric as they were exponentially increasing production volumes. Additionally there was a 3-6 month lag between shipping units and customer using units. So the quality was excellent up until volumes stabilized for 6 months. By that point the quality manager had gotten all the bonuses for high quality and left the company.
"I get a bonus based on the number of failures, so I have the techs continue testing until they all failed."
An test engineer got a bonus by predicting which units would fail. I pointed out the failure was common to all units not just the ones he picked. Seems that information got blocked with middle management, so they could get their bonus checks.
"35% failure rate! Is that what you expected?"
The manager shocked at the failure rate, I replied. "No sir that is not what I expected at all, the factory had a good week as it is normally over 50%." As it happened middle management had been hiding a few details to make numbers look good for bonus checks.
"But we had strong correlation"
This was the president of the company in the same meeting above learning that they had 50% end of line failure rate. He had thought the past fixes had fixed all the problems. The past fixes fixed a problem but not all the problems.. I explained that "correlation did not mean causation."
"Someone working on a problem will get it fixed faster than no one."
A manager told me this to which I responded if you have someone digging a ditch in the wrong place it takes longer to fix their mistake than digging the ditch in the correct place first.
"How many bugs are there in the firmware?"
A product manager asked me this, I answered "how many tests have failed?" They said "oh our tests are not good so we don't have failures." "OK when can you provide me the requirements?" "Nope we don't have requirements or requirement documents." So at this point you realize they have no requirements so how can you say something is a bug. "With out requirements and knowing what firmware should do it is hard to claim firmware has a bug, where it is not doing what it should." "OK, but then why are the customers complaining?..."
"Man that guy is difficult, he will not let any one see his source code."
This what an engineer said about another engineer. When I asked to see the first engineer's source code he said "There are no bugs in my firmware it is all in his, so you do not need to see my firmware."
"We were testing old hardware and old firmware and it appears that the unit had this failure, but we are not sure can you check it?"
"Why would you run old firmware and hardware?" "Well we don't have enough of the new hardware and firmware." "But the test is invalid because it was on the old hardware and firmware, and we have new hardware and firmware right here." "Yea, but is this a new bug?" "No it looks like the problem is the old bug, but you have indeed created a new problem by using old hardware and firmware which needs fixed."
"OK but what is the expected failure rate?"
So in a meeting the factory was shut down as they were having 10% fall out on a test in the factory. They asked me to determine what the root cause was. I requested two failing boards and two good boards from factory. This took so effort to explain why I wanted good boards and not just bad one. The problem was found to be temperature related, if the board was cold the power supply would not boot. I found that the good boards failed the test if they colder than room temperature. So I scheduled a meeting to discuss the fixes I had found. The quality engineer was in the meeting and asked me "OK if we do not fix this what failure rate can we expect?" "I looked at him and said well at estimated factory room temperature I am guessing it would be 10%" "Wow do you really think it would be that high?" "Yes I can guarantee it, as we have 10% failure in the factory."
"There salary is cheap so they don't cost us anything."
This was a manager talking about an engineer. This engineer was constantly messing things up. Not once did anything good come from his desk. The other engineers at company refused to work with this guy. Being the new guy I figured they were over reacting so I offered to help. After week of him telling me how smart he was and how he knew everything I talked to manager. I was informed that their salary was so low they were not costing the company anything. I tried to explain that they were cost the company because no one wanted to work with and because everything they did someone else had to redo. In the car world there is a saying "there is nothing more expensive than a cheap car." At least with a cheap car you can fix it.
"Your quote is too high, so let me help you"
A customer wanted a quote for a product I designed. Not a problem, so I gave him one. He came back and told me it was too high so he was going to help me. If I would send him the design he would have his engineers build the boards and make them. He figured for the 20 boards he would need he could build them for $250 each. So therefore rather than me charging him $6000 for 20 units I could just charge him $1000 to give him the firmware for the boards.