The Input Kludge AntiPattern

It is hard to think of the word "kludge" and anything other than an anti-pattern.  Thus, the input kludge antipattern is an obvious name.  This example of how not to code is focused on the concept of garbage in - garbage out.  When you allow data with questionable quality to enter your system, then it should be no surprise that the solution suffers in quality. Defining the Input Kludge AntiPattern The best definition I found this time around is on the DZone site listed with several other anti-patterns. [Click Here to See The Page] "An input kludge is a type of failure in software (an anti-pattern) where simple user input is not handled properly. This may cause a buffer overflow security hole, issues during deduplication, BI reporting, etc. The cause here is often caused by multiple channels of data insertions like Web Forms, API's, Mobility etc and few of which might be missed to implement the Frontend validations necessary. Here, the only long-term solution is to fix it at the source and have it corrected. But if the data is coming from a third party or might be due to mergers/acquisitions then solutions like Talend Data Quality, MDM, Data Dictionary might come handy." Note that the core issue behind this anti-pattern is a lack of handling input properly.  More often than not, the data input is not validated at all.  Of course, that makes sense if we rush through the implementation phase of development.  We throw some controls on a GUI panel and gather the input.  Validation is something we can come back to later.  However, this anti-pattern shows up when we forget to complete those critical validation steps. Too Many Cooks The good and bad news is that this situation does not always arise from our mistakes.  It is not uncommon for this anti-pattern to show up when there are multiple input avenues for the data.  This is also becoming more common as applications find more reason to integrate with other systems.  The myriad of sources tends to have varying levels of validation and general quality.  You might even find inputs that are entirely missing some data fields.  When you have a mix of formats and structures, it is easy to fall into an anti-pattern like this. Nip It In The Bud The best way to avoid this anti-pattern is to control your data as close to the source as possible.  When you have access to the primary data entry point, then validate there.  When you are accepting streams from other sources, then validate as soon as you receive the data.  Do not be afraid to reject data or toss it into an exception bucket.  Keep it out of your system until you are comfortable with its quality. A good example is an XML format that verifies the required fields exist and then apply the field-level validations.  Yes, this approach can increase processing times.  However, it is easier to reject bad data than guess how to correct it.

There are no comments yet.

Please log in to write the first comment.