When a new model malfunctions right before ship, why is the software guy always blamed?
I work as a software developer (BS in Computer Engineering) for a wire saw company. Several of the wire saws for years had a random problem of wire running off the reels, but it was considered a minor problem. A new saw model that was being built was bigger and had multiple cutting yokes. According to the schedule, we had a month; until sales told the customer we could deliver the saw in two weeks (the senior project engineer said we needed two months). The mechanical/hardware people handed over the saw a few days before the shipping date to software where all we had to do was load our usual software (modified), test, and ship to a happy customer.
Then the fun began. Each cutting yoke had unique problems and all of them had run-off problems. Mechanical and hardware assemblers said it was obviously software. Being the only embedded software engineer on this saw, all their eyes fixed on me as the bottle neck in their finely tuned organization. During the meeting, it was decided that everyone had done their job using the same mechanical/hardware as other saws before and did not have these new problems, so it was time to own my job. In a few hours of testing, I came to the conclusion that the same software running on several parallel yokes but displaying different problems was indicative of hardware malfunctions or miss-wires (with several hundred wire screws, this had happened before).
My logic was not accepted, and it was seen as trying to blame others for my buggy software (again, everyone did their job and I was the FNG who replaced an uber engineer, who over the years could do backflips on water while juggling anvils). Over the next few days, I was called to frequent meetings to give updates. After a few rejections by the technicians of my idea to check the wiring, I grabbed a screw driver and after a couple of eyeball scans looking for differences between each yoke's hardware, found several miss-wires in each yoke. Now the software was running uniformly on all the yokes. Upper and middle managers left their meeting room and asked me on the shop floor what I had fixed in my software; I said it was a just a few mis-wires. They looked at each other with even bigger scrunchy faces and ran back into their meeting room (no atta boys).
This still left the reel run off problem that now plagued the saw. Again, after several meetings, I still needed to fix my software problems and ship that saw. By this time management called back the uber engineer and another engineer to get their HMI/data-logging program to work "even better" (no, not buggy at all) and I contributed a few minor "improvements" they missed while interfacing the hardware, but I digress. I was under the microscope to fix the reel runoff problem that I had obviously made worse with my new software and my manager made the casual comment that younger engineers work harder. I was bouncing between the shop floor and my small office/file room making changes and not progressing.
On my office desk I cobbled together (out of replaced parts) a test saw to test my software (management promised engineering their own production saw to develop SW on, but it never transpired). At first, software changes took 20 minutes to load and verify (walking to the shop with an eeprom). After a few months of begging for a debug eprom and an IDE, I was now able to make software changes in seconds. In my office the software worked correctly on the test saw but randomly failed on the production saw. During even more meetings I showed that the problem resided in a single line of code that looked at the ADC to detect wire speeds, but this was questioned by sales--why did this LOC now fail when it has been working fine for five years in all the other saw models? Running the IDE on the production saw would prove my point. Earlier, I had requested a better laptop to run the IDE on the production saw (engineering had an older Pentium laptop while management/sales had P4/Core). Alas, I used the old laptop which resulted in a lot of crashes due to IDE lag times. This impressed everyone when crashes now spewed wire everywhere. The technician (who wired the saw, dropped an oscilloscope, and later broke a laptop) kept moving my laptop while running tests every time it was in his way. Eventually, the IDE showed that the ADCs, even though receiving the correct stable voltages, had a sizable ripple that prevented zero speed from being detected by the LOC I predicted was the one causing the wire to runoff the reel.
Because the test saw did not have this problem, it was a simple process of ceteris paribus that indicated the 18' lengths of display cables caused the ADC's levels to ripple. I shortened the display cables to 6'' and the saw functioned correctly. Upon showing the technician the problem, he commented that customers were not going to walk around and open the cabinet to use the saw displays and it did not look professional. My ennui kicked in and remembered the story he told months earlier of another difficult saw project he worked on that bankrupted this company thus leading to the present management team. After consulting the embedded board manufacturer, another engineer and I designed a display buffer that fixed the problem. The saw shipped, my job description no longer existed in the company, and when parting, my manager said I needed to "own my job." They then hired a son’s young friend to do a "totally different position." He didn't last. Ironically years later, most of those special people were purged. The remaining engineer wrote a recommend stating my HW/SW solutions were still being used in their current saws.
Most of us work in some sort of chain, (or tower, if you prefer), producing work that depends on others, and is in turn depended on. (E.g. business or functional logic encoded in software that depends on hardware to work. I've always felt it desirable to have at least an outline understanding of the neighbouring fields. Hardware people need to know something about physics and chemistry on one side, and software on the other. Similarly, software types need to know a bit of hardware and some business, and so it goes on.
Sweet. Ten years later after I worked for a certain solution “froward” company that my EEtimes story was based. In a recent 2015 interview one of those special people, who is no longer with said company, told an interviewer something that was strange and likely not true, if what was said was really said and not redacted. I asked for clarification from the interviewer about what was said or if they even had the right person and the interviewers are being tight lipped about who spewed. Just goes to show that if you do the right thing for an employer and they ultimately benefited, the ex-sycophants still years later whine that their obtuse behinds which they roasted in the fire for years was scorched and was my fault because I came by and pointed out they may be happier turning around. Makes me wonder how many other of my interviews/jobs these people have ruined over ten years.
I worked for a company for 12 years designing a range of fibre optic switches. (check out the spelling of fibre!)
My bit was the opto-mechanics. I can sympathise deeply with the sentiments in these posts. Guys, I feel your pain. One of the posts earlier mentioned that it is obvious when mechanics isn't working, but not so software and electronics. In the fibre switch, the mechanics was small and delicate, and small mechanical disturbances (thermal, vibration, electrical noise) could make a difference but it wasn't obvious by observation. When there was a problem the blame was assigned thus:-
1. it's a mechanical problem, the mirror is in the wrong place (it was once many years previously but not on the five plus subsequent problems)
2. Right, the mechanics is OK, must be an electrical problem
3. Right the electrics is OK, must be a software problem
Usually the 'head in charge would decide on what the root cause was and waste time and money trying to fix something that wasn't broken. The three disciplines had enough respect for each other to get on and sort the problem (eventually when the management "help" had evaporated when the solution was looking intractable)
Oh, and I relate to the story above about the saw project that was estimated to take 2 months scheduled to be done in one month and quoted to the customer as 2 weeks.
I don't work for that company any more :-)
Fresh real-life example: A few weeks ago I released code that worked exactly as expected on prototype hardware. When used on the next board-spin of prototypes, it didn't work, which of course meant it was a software fault. Yesterday it was proven that not only was the circuit changed, but a wrong part had been used on the dozen proto builds, so it wasn't even the proper changed circuit. Put in the right part, and the software works again. Gee, what a concept.
This is the second story about the hardware induced noise I read here. Since noise mixed in a signal is so common and most of the time it is random, problems happen here and there somehow give a hint, even not strong and clear.
A specific software in general will hardly produce random troubles here and there.
Software and hardware are often trained by management to blame each other :-)
(As in: when the "real" mission to create and ship and SUCCEED [as a team] is derailed into the "fake" mission to grab credit and avoid fault, this blame-game usually results...)