Hard to have hysteresis when the software that governs Burn Rate is executed in a dead-nuts fashion of timing; exactly every 2.5 milliseconds. Excellent solution, in my view. As to the issue of communications with management, we are getting there. Just a little more setup is necessary. When testing my solution, it came to pass that we members of the team visited a physical site where motors were actually allowed to burn. Our team was not then at the burn stage but the support environment (measurements, timing, recording of events) was quite well suited to integration testing (my favorite laboratory). This is where the fun began. You see, when doing most of the development work, I was seated in a well air conditioned laboratory; not higher than 70F. The test site was not air conditioned, and we were working in the Summer, in Sacramento. It gets hot in Sacramento. As it happened, the motherboard did not like those Sacramento test facility temperatures. 100F is common there. While testing the motherboard (and my integrated software) at the test site, it would happen that the system as a whole would fail. What few facilities were then implemented by SWRI and their contractors gave me messages like "address exception" and the like. Now, I admit that I was then using the Microsoft C compiler (was it 5.1, 5.4? some version suitable to the development of commercial software), and so it might have been possible that compiler generated machine code would elicit an "address exception." Yet, I highly doubted this point. The nature of the errors was always obscure, and never seemed to occur at the same address. Really, not at the same address? Software does not work this way. Software is rigidly deterministic, and so errors tend to occur in the same location. How did I know that the error moved, in terms of associated memory address? Easy. Very easy. Take an oscilloscope and attach its input to a output of a "pintle" (a kind of valve used to control thrust vectors in rocket motors) and adjust the position of the pintle in software. That way, you know where in the software that the error occurs. You get a graph, every 2.5 milliseconds, and when that graph differs, you have located an error in software, since errors cause the machine to halt. The graphs changed, for every run. The errors never occurred in the same place in memory. This technique is called "Picket Fencing" the putting of change in some physical feature as a means to show execution progress in software. What really sold me on the notion that the problem was in hardware, and not software, was the magical moment when the report error was not "address exception" but "opcode exception." I admit to being biased against anything associated with Bill Gates; does he have a backdoor in Windows? Yet, it seems reasonable to me to expect that his C compiler would not produce code that includes problematic instruction; most specifically, opcode exceptions in target processors. One point I have not yet mentioned is the derision visited upon my person because "Your software is the problem." The classic battle between hardware and software; who is at fault? Here is where the juice begins to flow uncontrollably. When I got the "opcode exception" that is when Aerojet management decided to actually get involved. There was a team meeting between those of Aerojet working on MaxPac, and those of Southwest Research Institute working on MaxPac. During that telephone speaker call, I lost all further patience. I challenged the SWRI personnel about their choice to both mutilate the microprocessor (and Intel 386EX) such that I could not attach In-Circuit Emulation/Monitoring hardware (would have been very useful for debugging this kind of problem), and a number of other things. Indeed, it got very hot, very fast. The man who hired me for this position, Fred Perz (for whom I have great admiration) later noted that from his experience, he had never seen somebody get that angry that fast in his life, as I had apparently demonstrated with the SWRI manager who was speaking to me. This is the point that you are discussing, Mr. Healthy Software Developer. You choose to be meek, and I choose to throw it in the face of management.

This brought a group of three Aerojet team members (myself, Fred, and the author of the Burn Rate) to visit the SWRI site in San Antonio, Texas. As I recall, we were there for three days. The details of the three days are not important; only the last few hours are important. First, the SWRI facility was well air conditioned; this is not a trivial matter. In those last few hours, before we Aerojet team members would have of situation been required to go back home with our tails between our legs, came redemption. For all the quality engineers (certainly, highly paid personnel), they could not duplicate the errors that we Aerojet team members (i.e., me) observed on operation of the hardware. Yet, from the next floor up (the area we were in was an atrium, with two or more floors of offices looking into that atrium) came a technician, who was interested in the work we were doing. The SWRI engineers told this female technician about the problem they were looking for, and how they had not found it. Her response? She pushed on one part of that motherboard, and the problem immediately manifest. That part was the one that had three big lugs, and controlled the voltage and current that was supplied to the 80386EX microprocessor. The problem is that the 80386EX expects that voltage and current supplies are absolutely accurate, else the process does not properly operate. Such details are the province of hardware, not software. So much for the quality of hardware engineers who worked on the MaxPac project. I won that argument. And, I was a bastard about it. All because I had been subjected to six months of ridicule over the quality of my software. Aerojet personnel demeaned me because their supplier, SWRI, sold them shit. Keep that in mind if you ever decide to work for either company. So, what was the problem? A voltage/current control regulator. This device had three lugs; big lugs. Not like connections you find on an integrated circuit. Each was surrounded by glass dielectric. The problem with the MaxPac controls is that this part had been inserted into the motherboard, and then bent over, in order to account for height requirements, such that the whole seat, control, rocket motors, etc, could fit in the airplane cockpit. And there is the rub. If you are not very careful, when you bend over the lugs on such a part, you break the dielectric. You break the dielectric, you change the electronic characteristics of the part, and since it governs microprocessor operations, no wonder you experience errors like "opcode exception." All of this is to say that ultimately, what I as a programmer found turned out to be a manufacturing problem, and if I had not been willing to place my balls on the table, this problem would likely never have been corrected. Did I ever receive so much as a thank you from Aerojet management? No. And is that surprising? No. So, in the end, and to your point, be careful of who you work for, when you are a programmer, because your clients have no idea what it is that you do, and so they will blame you for every problem that comes up. When you find them, just solve the problems, build a report about that problem and how you solved/fixed it, and wait until someone else notices that something works when it did not previously work. Then, show your report, and tender your resignation. They will beg you to stay, and that is when you should tell them of all their shortcomings and why you would be an idiot to continue to work for them. That is the only leverage that an employee has.

It's not always fun to share this stuff. I appreciate you being open.

I'm so sorry to hear this. It never works well to call other people out in most situations in my experience. Instead, I do a good job and try to improve my perception and build confidence.

I'm not so sure it's any better in other engineering fields, unfortunately. Much of this is just the nature of management and relationships.

Couldn't agree more!