Recently I was reviewing a production issue with one of my developers that involved 'bad' data from a third party application blowing up one of our proprietary processes. We do a lot of ugly 'data proctology' like this and don't have a lot of control on the front end. It is what it is. Our conversation caused me to revisit several old topics.
I'm The Garbageman
"Garbage In, Garbage Out". GIGO. It's an ancient phrase when you consider the short lifespan of computer technology. Many refute the validity of this concept. The argument is that 'bad' data shouldn't be allowed into a system in the first place, and if it does make it in then it is a failure on the developer's part. I tend to agree, and defensively program to prevent GIGO.
That being said, for better or worse, I think like a developer and so code safeguards accordingly. That means I am not thinking like an end user, and so am going to be outwitted almost constantly. I simply can't think the way that I need to in order to account for the myriad things that a user might do to a given application. (I actively practice trying to put myself in a user's shoes- remember, users are NOT the enemy.)
There are many testing techniques- automated and manual- that can also help preventing GIGO. Unfortunately, I've yet to be employed by someone who permits the time to develop comprehensive automated test suites because of the time required. Companies have slowly admitted that Quality Assurance departments offer a positive ROI, and I hope that they come around regarding automated testing as well.
I realize that QA testing was a tough sell to corporate America (and I guess the entire world's business entities), because in many cases the argument was quite academic:
If we hire people to test our software then we'll have a higher quality product. If we have a higher quality product then we will spend less time working on defects. If we spend less time working on defects then we will have more time to develop new features and enhance shareholder value in ACME Corporation.
But what if ACME Corp's software didn't have many bugs? How do you prove a negative like that? (That's a rhetorical question and I currently don't have the answer.)The Void
Our production issue had taken us beyond GIGO into the realm of GINO ("Garbage In, Nothing Out"). Our process crashed as data was extracted from the source application. And here is where I think that we could do a better job defensively coding around the input and gracefully failing if absolutely necessary. Since we don't have a user interface- or a user!- we can't just present a validation failure message or the like. (The source application is quite deficient in the area of input validation anyway.) Fuzz testing might be one technique that could harden our vulnerable process. While this might seem like overkill, we unfortunately don't have total autonomy over how some of our processes are consumed so would need to test for a wide range of issues.
Update
I recently encountered a new variation of GIGO that involves requirements. Insufficient or overly broad requirements yield garbage as easily as bad input data.
No comments:
Post a Comment