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.
Yes, sometimes it is both. But we mustnot start pointing fingers before exploring the problem and what the cause is. I recently spent two days troubleshooting a problem and have worked with the HW engineer to try and determine the cause. So far, we have elimiated SW as being a possible cause to the issue.
The software guy looses respect, because he caused the product to be late in the first place.
It doesn't matter if it was a HARDWARE problem, we get the short end of the stick; because we fixed the problem after everyone said the product was ready to ship.
In the groups I manage, when there is a bug both hardware and software are considered guilty until proven innocent. Hardware and software engineers are expected to work as a team. As mentioned above software often fixes hardware problems. Also hardware debugging techniques are sometimes helpful in tracking down a software bug. Management should not allow the different disciplines to blame each other.
Why should the software guys lose respect?
Make sure that it does not get framed that way. Make sure that the software guys get the credit for turning around a multi-million dollar loss.
If you want recognition in a company then the best way to do that is to make an association between what you do and the performance of the company. Demonstrate **value**.
In your performance review, point out the value of what you did.
Mr. Fyock, welcome to the monkey house. Your best strategy would have been to quit, although for sure that is not always a feasible solution. Since idiotic management and moronic sales types have a tendency to butt into engineering (software and hardware) you might want to consider this advice that I was once offered: "the time to start looking for a job is the day you land your new one." Sounds cynical? Wait until you've been in the field for, let's see, 11 minus 74, ah, 37 years, and consider it again. Well, in any event, we've all been there...
The trouble is, when you find a software WORKAROUND (emphasis important) to a hardware PROBLEM, and all that people remember is "we had to rev the software to fix it", the software side loses respect - including at review time.
There are two reasons for that:
1) It is relatively easy to see how hardware works and much harder to see how software works. That means people will always tend to believe the problem is where they can't see it (ie. in the software).
2) It is also a matter of hope. Software errors can be fixed on short deadlines, but not hardware errors. Thus management/sales people always hope it is a software problem. When a product is on stop ship they will readily believe anything that gives them hope that a solution is at hand.
Even if it is not really a software problem, there is often a software solution. Whenever this happens it becomes a software problem.
I once had to fix a lubrication problem in software. Without that, many idetms would have had to be recalled and scrapped costing the company a few hundred thousand dollars.
On another occasion a mechanical stop was repositioned. This could have cost approx $100k and 4 months to fix mechanically meaning the company would have lost a few million in sales. I fiddled for a day and found a software solution.
At the end of the day, all that matters is that a solution is found. The customer doesn't care what is broken or who's fault it is.
Just work together to find a solution. Everyone is trying to earn money for the same company.
Nobody has an exclusive right to make the mistakes, that is for certain. The problems arise when either the product definition is fuzzy, or the designer makes a mistake, or the builders don't follow the drawings. The funniest one that I experienced was a fairly simple circuit that I had designed and then built. I carefully selected the resistors to all be in the middle of where they needed to be. But when the production model was built, it was miles out of specifications. The problem eventually was traced to the arrogant detailers who did the circuit drawing. They corrected the "Mistake" made by "That dumb engineer", and added the "K" that I had neglected to put on several low value resistors. So instead of 22 ohms and 470 ohms there was 22,000 ohms and 470,000 ohms. The shortcoming of my designs are that they don't work as intended unless they are built as designed. This was reported to my manager at my next performance review, when the problem with that product was brought up. The response was "OH".
Been there, done it, got the company golf shirt. Years ago we had a hydraulic problem, excess pressure when braking. The redesign fix was messy, even for hydraulics. The $1M machine was down and people were not happy. I suggested a SW workaround to control deceleration, which we did and were soon back up running. However, word got around that I had to fix the SW to get the machine running. Unfortunately now I have to think twice before helping others.
Sometimes this is all in the software domain. Reviewing DOS driver code while writing new interface code on an ISA plug-in board, I found some code that seemed to have a race condition and asked about it. Since this had been written by one of the original product group, now a technical leader, and had been working for years, my question was disdained and dismissed out of hand. A mere few months later, intractable customer problems were blamed on my interface code. I finally traced it back the the same DOS driver code. Turned out this was the first customer PC system we had seen at whatever speed it was (500 MHz?) and it was the first time that the PC was fast enough to catch the race condition. Now it was still my fault for not having pushed harder when I found the problem before.
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.