Go | New | Find | Notify | Tools | Reply |
Member |
From where do new SW developers come such that they have no idea how to gather comprehensive requirements including exception handling? I've been using a Moen Flo device for awhile now. It's actually been pretty good and I think it will be a great device if there is actually an emergency water leak event. It's good to have. That being said, I don't know what happened but it's going through a phase of re-learning and assigning water usage to fixture types. When water gets used, it tries to assign it to a fixture like faucet, hose, bath, irrigation, shower, toilet, appliance, etc. When I first got the Flo installed, I went through this and it learned pretty quickly. Again, not sure what happened but it's going through a re-learning period. And for some reason, EVERY FRICKIN WATER USE EVENT GETS ASSIGNED TO HOSE (ie - outdoor garden hose). Doesn't matter time of day, flow rate, duration and other information that may help discern what type of fixture is being used. It doesn't matter that I've gone through through HUNDREDS UPON HUNDREDS of events to properly re-assign fixtures for each usage to help it learn. The fricken FLO thinks every time water is used, it's the outdoor hose. Now, if there is a leak, this thing is supposed to be able to discern a leak vs normal usage. So, if it thinks it's a hose, it's fine as long as it can figure out that something (ie - the washing machine) is leaking. But if it can no longer figure out something is leaking in a reasonable amount of time, the Flo is now worthless. We'll see in another week or so if it corrects itself. But for fuck's sake, who are these developers and QA people? Is nothing coded well anymore? Is nothing tested anymore? Fuck yea, bring on AI. Can't wait to see how bad these developers can really fuck things up. "Wrong does not cease to be wrong because the majority share in it." L.Tolstoy "A government is just a body of people, usually, notably, ungoverned." Shepherd Book | ||
|
אַרְיֵה |
Our rule of thumb, back when I was working on call processing software at Bell Labs: typically, 15% of the code was for normal call processing, 85% was for error handling. Our test teams and QA people were really inventive when it came to introducing unexpected inputs to the system; they took delight in trying to break the developers' code. By the time anything was released for use, it had really been wrung out. Telephone call processing was about as failure-proof as code could be. הרחפת שלי מלאה בצלופחים | |||
|
Don't Panic |
IMO the emphasis on getting software QA done right changed as soon as software and firmware stopped being shipped on expensive, unchangeable media. Up to that point, making a mistake was both expensive and slow to fix as you had to scrap diskettes/ROMs/DVDs/BDs and sometimes remove and replace ROMs on circuit boards to get rid of the buggy code. Rework/scrap costs like that were very visible and managers tracked them, so testing was rigorous to minimize those costs. Now that updates are done routinely over the Internet and even firmware code winds up on Flash storage, the urgency to get it right up front is largely gone. My programmer colleagues got irritated by my calling code updates 'bug swaps' but has perfect code ever existed? So, yes it is a positive development that code updates are easier to get and use, but it's no surprise the testing impetus at the factory lost the edge when errors stopped costing them money. | |||
|
Powered by Social Strata |
Please Wait. Your request is being processed... |