A recent system glitch reminded me of the challenges and joys of finding points of failure.
Since wrapping my mind around and getting my hands on technology at the age of ten in the form of a multi-project electronics kit, I've been seeking out points of failure in systems. I didn't realize how invaluable this seemingly imprecise skill would be until arriving one day in computer lab at college when a classmate stopped me as I was walking around to my workstation and asked me to take a look at a bit of code he was struggling with.
The compiler wasn't reporting any syntax errors and the code segment appeared to be working perfectly, but the running program produced a final result which was nowhere near the correct value. It was so way wrong that its wild value was rather jarring to see. That inexplicable value had completely flummoxed my classmate to the point of triggering blinding frustration. I turned and approached his workstation to have a look.
He rose from his seat and offered his chair to me even though he had a severe congenital affliction which prevented him from standing comfortably for any length of time. I never asked him about that, guessing at the time spina bifida, but it was obvious enough that I motioned for him to sit back down and asked him to walk me through his code, line-by-line. I dreaded the thought of keeping him on his feet too long while I tried to track down the runtime error. He sat back down and began walking me through the code segment descriptively. This was before we had source-code level debuggers, let alone multi-windowed visual integrated development environments with rich graphical user interfaces. We had to glean full understanding of the programs we coded entirely in our minds, thinking like computers sequentially executing commands, to track down such sneaky runtime errors.
My point of failure thought processes kicked in and within less than five minutes I had spotted the problem. I pointed it out to him without telling him exactly how to fix it by using a different conditional operator. Instead I posed a question about what the operator he was using would actually accomplish. He thought about it for a second, his face lit up from realization of his bad choice of operators and changed it to the proper one, recompiled, ran the program and the correct result was produced. Again he rose from his seat and thanked me with more enthusiasm than I thought I deserved. I reinforced the fact that he figured out the correct operator on his own after I simply wondered if that could be causing the error.
"Well, you were the one who opened my eyes before lab time ran out," he replied as he copied his code to floppy and prepared to leave for a class, and that's when I realized he had been effectively blinded from mounting frustration as the ever-present time crush pressed.
"Just another set of eyes on it," I said and went to my workstation, already reflecting on the experience of finding the point of failure.
Night before last Mom alerted me to the fact that water pressure in the house had suddenly dropped to zero. No water was flowing from the taps. It was dark outside and a thunderstorm was rumbling noisily over the farm at the time. Great. But I had helped my parents build this place from the ground up, including the water tower attached to a shop building which has expanded over the decades much like the Winchester Mystery House did before Sarah Winchester's death. I know how the water system works, so to the shop I went.
Out in the shop building, after a moment of gazing at a confusing mass of wiring and breaker boxes used for controlling the different components of the water system, I checked the pressure booster which was not pumping water even though it was humming and its motor housing was warm to the touch. After switching it off, I climbed the water tower and opened the tank to see it was empty. Totally drained. The pressure booster had been pumping air for who knows how long. I hoped it had not burned out and wondered if the worst had happened and the submersible pumps in the water wells had failed...or maybe the relay switch controlling them had. Or maybe a lightning strike had blown something in the system. Something difficult to find and repair.
Thunder rolled, reminding me I really shouldn't be up at the top of a steel tower while lightning was striking so vigorously in the area. But before I hurried back down the ladder (totally made of steel) something made me reach down and shake the float switch hanging at the end of its short, rubber-coated cable. Water immediately began to flow into the tank.
That meant the submersible pumps at the bottom of the two water wells had kicked on when I shook the float switch, which meant something in the float switch was probably corroded or warped by time and temperature swings enough to keep the moving parts from moving as smoothly they had been for decades now to open the circuit triggering the relay switch to send power to the submersible well pumps.
All of these thoughts raced through my mind before I had the tank lid screwed back down and was quickly but carefully descending the steel ladder, all the while marveling at how it all came together so rapidly to reveal the point of failure. Unfortunately, the booster pump did indeed burn out after running dry too long which is a bummer since it's not exactly a cheap system component to have to buy.
It and the float switch must be replaced now, but thanks to a lot of well-crafted software developed to make online shopping for stuff like a new 1.6 HP booster pump and a Class LG cable float switch water level controller a breeze, those new components will arrive here at the doorstep in about a week to replace the failed ones. In the meantime, gravity will keep water flowing from the now-full tank at the top of the water tower down to the house and garden taps for daily use. With point of failure quickly identified it's just a matter of a little bit of work installing the new components when they arrive to once again enjoy fully pressurized flow of water.
