Develpreneur: Become a Better Developer and Entrepreneur

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.

The ambiguous viewpoint anti-pattern is one that goes to the heart of object-oriented design.  We want to abstract and isolate functionality in a way that follows a pattern of logic.  This goal is often achieved, in part, through segmenting functionality by viewpoint.  Thus, we have the business, data, and view related code grouped in their separate areas. Defining the Ambiguous Viewpoint AntiPattern I found a good explanation of this anti-pattern on a page worth checking out for several others as well. [Click Here to See The Page] "Object-oriented analysis and design  models are often presented without clarifying the viewpoint represented by the model. By default, this models denote an implementation viewpoint that is potentially the least useful. Mixed viewpoints don’t allow the fundamental separation of interfaces from implementation details, which is one of the primary benefits of the object-oriented paradigm." The definition above helps highlight an essential point of object-oriented design.  If you decide to use it, then do so wholly and correctly.  When you choose to use OOD principle only in select cases, then it tends to make the solution worse rather than better.  It can even lead us to spaghetti code situations.  All-in or not-at-all are your two choices. Design Before Code The most common way to fall into this anti-pattern is to code as you go without considering the design.  It often appears in source code that was created with a heads-down approach.  We get into a groove of writing features and skip the step where we think about where they should live.  It is almost a convenience based anti-pattern.  There may be a method to our madness; however, that does not provide comfort to those that have to maintain our code. Pseudocode To Success There are many ways to avoid the ambiguous viewpoint problem.  However, I find that one of the best solutions is to use pseudocode or comments before coding.  This simple process forces you to think a little bit before you code and slows us down a little.  This time for reflection and design may be just enough to help us consider that maybe we are doing this in the wrong location.

Velocity is an important part of modern software development.  However, there is also that adage that "speed kills."  Therefore, we need to strike a balance to avoid the "walking through a minefield' antipattern.  We have to avoid throwing away quality in our pursuit of quick turn around times. Defining the Walking Through a Minefield AntiPattern In this case, the name of the anti-pattern may be the best description.  However, we can add a little color to it. [Click Here to See The Page] "Walking Through a Mine Field, as the name adequately suggests, is a situation encountered, most often, with software components and products which are not adequately tested and thus have residual bugs. These bugs turn up at critical times, for instance server overload etc. The name is given to this antipattern, possibly because one is never very sure of the effect of the untested/poorly tested component/product and thus lives in a constant fear of system failure." The bottom line of this antipattern is the lack of quality.  We often attribute this lack of quality to a focus on speed and taking shortcuts.  However, there are cases where quality is just not a consideration in the creation of software.  In any case, we can avoid falling into this trap by giving quality assurance and testing the respect they deserve. Just a Little Change The easiest way to avoid the "walking through a minefield" antipattern is to ensure that our software is tested before release.  Unfortunately, this is easier said than done.  There are "quick" fixes and minor changes we see that can turn around a broken feature.  These lead us to the temptation of pushing through the "little change" without following the processes in place.  The dirty little secret is that there are no little changes.  Even the slightest change can introduce a new bug or have a typo that crushes the system.  Thus, we need to make sure we have proper checks and balances in place to reduce the chance of such bugs going to production. Lack of Understanding While the most common reason for this antipattern is a lack of quality, there are also cases where communication is the culprit.  In these cases, the problem solved by the software team is not the one users are focused on.  It may be due to subtle differences in understanding of the problem.  However, those little details can be frustrating to the customer when they are not being understood.  We need to remember that software tends to be complex.  We can follow the "measure twice, cut once" approach by slowing down, asking questions, and then following best practices.

Over the years, we have built tiny up to large systems that provide a launching point for other applications.  These solutions are built on the hard work and ingenuity of those that went before us.  Therefore, we want to take advantage of that work and not have to reinvent the wheel.  When we customize our solutions in a way that breaks our ability to continue to take advantage of a product, we have achieved the dead end antipattern. Defining the Dead End AntiPattern The simplest definition of this anti-pattern may be the best. [Click Here to See The Page] "Direct modification of commercial software or reusable software creates significant maintenance burdens for a software system." In short, a dead end occurs when we customize the code of a vendor beyond where they will support it.  Thus, you have voided the warranty and will not be able to take advantage of future upgrades, enhancements, and patches.  You are now on your own. It Is You, Not Them The first item of note with the dead end antipattern is that this is a reflection on your choices.  The vendor will be able to move ahead and make changes to their system.  Likewise, you will be able to enhance your solution.  However, you will not receive their updates and may have to replicate the features that would have been provided as part of being a customer.  This antipattern is more about an increased workload than an impossible situation. On the other hand, there might be critical upgrades a vendor provides that are critical to the long-term viability of your product.  Operating system support is an example of this situation.  The version of the software you are on when you make the dead-end choice might not support future OS versions.  This situation occurs when you have new technologies such as we saw in PC OS advances during the nineties and early two thousand's.  When Windows XP came out, it might have made your Windows 95 software unusable.  A simple upgrade would fix that, but you could be blocked by a dead end. Design and Frameworks The most common way to bump up against this antipattern is through frameworks.  They are likely to be extended due to their nature.  However, when you do so in an improper manner, you can stumble into a dead end.  The solution is to build on top of vendor products and frameworks.  Do not give in to the temptation to change core code just because it is available.  There should also be abstraction layers in place, where applicable, to allow you to change the software on the other side of that layer.  When you design a solution this way, you still will have an impact on changing the platform.  However, it will be fixed by some mapping changes and not run you into a brick wall.

We all do it.  There is a chunk of code that almost does what we need.  So, we copy and paste it where we want it then make some modifications.  When we do this in our systems instead of proper code re-use than we are implementing the Copy Paste AntiPattern.  Now let's look closer at why we should avoid this. Defining the Copy Paste AntiPattern I want to use the Wikipedia definition for this anti-pattern to help us get a better feel for when and how it may occur. [Click Here to See The Page] "Copy-and-paste programming, sometimes referred to as just pasting, is the production of highly repetitive computer programming code, as produced by copy and paste operations. It is primarily a pejorative term; those who use the term are often implying a lack of programming competence. It may also be the result of technology limitations (e.g., an insufficiently expressive development environment) as subroutines or libraries would normally be used instead. However, there are occasions when copy and paste programming is considered acceptable or necessary, such as for boilerplate, loop unrolling (when not supported automatically by the compiler), or certain programming idioms, and it is supported by some source code editors in the form of snippets." Note that there are some situations where it makes sense to use this anti-pattern.  However, those are due to limitations and not ideal.  That makes this an anti-pattern and sometimes a workaround but never the best solution.  Think of it as an incremental step towards a solution.  Therefore, while it may work, for now, we want to abstract or automate it in the future to provide the best approach.  Even templates follow this recommendation.  They are useful but are best when we automate the creation of that code instead of copying and pasting templates. Epidemic Bugs The biggest issue this anti-pattern can create is an infection of your source code with bugs from the source material.  If you catch the bug early then you need to change the code everywhere it was copied.  If you are not that lucky, then you may find yourself facing the same bug over and over as it appears in the various copies.  The result comes from two problems in the copy paste antipattern.  We are not sure the source s perfect code, and we do not have a way to track all of the copies of the source quickly. For example, we can copy A to B and C, then copy B to D and E, C to G, etc.  We have copies of copies and quickly have no idea have pervasive that bug is.  Even worse, we may fix the bug several times only to have QA point it out to us again not realizing they found a new bug. Fixing The Problem The fix for the copy paste antipattern is not a one and done solution.  Once you see a code block appearing multiple times, you should abstract each appearance into a single function or method.  Then you will be able to refer to that new function as you find other instances of the code block.  That means you may have this anti-pattern in your source for a while.  However, eventually, you will roll all those pasted instances into a properly designed and tested function or method.  You also gain the benefit of testing that section of code over and over as you roll in code from across the expanse of your application.

While lava is hot and deadly early on, it becomes hard to move once it cools down.  The is the thinking behind the name for the lava flow pattern.  This anti-pattern is one that occurs for more often than one would think and can be quite tricky to clean-up. Defining the Lava Flow Anti-Pattern There is nothing like a rant blog entry to give us a good definition for an anti-pattern. [Click Here to See The Page] "Successive, well intentioned, changes to architecture and technology throughout the lifetime of an application can lead to a fragmented and hard to maintain code base. Sometimes it is better to favour consistent legacy technology over fragmentation." In my experience, the most common trait of the lava flow anti-pattern in projects is that several developers historically worked on them.  Every developer has their own experience, and when they dive into a project with their approach as opposed to matching the current standards, then things become complicated.  In the best case, it is easy to see that several developers wrote the code.  In the worst cases, the lava flow pattern appears, and you have all sorts of technologies and halted attempts at a solution.  It makes maintenance feel like wandering through a complex hedge maze. Demos Gone Bad While varied developers is a factor that contributes to the appearance of this anti-pattern, another common misstep is turning a demo or proof-of-concept into a product.  Take it from someone who has written dozens of these such one-off programs in the past.  There is often some ugly code and incomplete thoughts buried in the source.  We rarely clean things up since we are under the gun and assume no one else will use that code.  Unfortunately, there are times where the demo is good enough that someone decides to productize it.  Put another way, when there should be a design and product created from scratch we sometimes skip those critical steps and build out an existing proof-of-concept.  In these cases, we are building on a partial foundation or one that is not intended to be weight-bearing.  That starts us into building a house of cards before we have even released the first version.  Needless to say, this is not a recipe for success. Correcting The Anti-Pattern I would not do a solution justice without first mentioning ways to avoid this.  There are a few considerations to keep in mind during your coding to reduce the risk of this. New and Shiny are not always the best.  Do not throw out existing ideas and concepts in a project without good reason. Use version control to branch your theories and trials away from the code base.  You can always merge them in later if they prove out. Understand existing standards and guidelines before diving into coding.  You will be better served by understanding how things currently work rather than bringing your genius to the project in a vacuum.  Maintaining a system takes work and can be frustrating.  Go with the decisions made by those that have gone before you. Now that we have those out of the way, we can talk about fixing a lava flow.  It is not easy.  There are often some pieces of the various technologies that still used and an essential part of the system.  The first step is to pick one approach among the ones in the system and go with that.  At least the new code will start to look similar.  As you address technical debt and fix bugs, you can begin to convert the other approaches to your one choice.  Make sure you keep this in mind during code reviews and the like so you can hold the team accountable for slowly making the corrections and merging the varied approaches into one.

Best practices are like everything else.  There are times to ignore or break the rules.  The anti-pattern we cover in this episode results from not doing so.  The poltergeist anti-pattern occurs when we have a bunch of infrastructure code that serves the design but is otherwise useless.  When you are creating methods and classes solely as place-holders or pass-throughs, then you are feeding this anti-pattern. Defining the Poltergeist Anti-Pattern Once again, I found the best definition for our purposes in a blog article about anti-patterns. [Click Here to See The Page] "Useless classes with no real responsibility of their own, often used to just invoke methods in another class or add an unneeded layer of abstraction." You might think of these sort of methods or classes as "filler" much like the stuff in boxes when you are shipped an object that could bounce around in its package.  However, shipping filler provides more value.  The challenge is that there might be a fine line between short methods and poltergeists in your thinking.  In that case, you can find guidance in this post, discussion, and comments. Design To Taste The most common source of the poltergeist anti-pattern is a designer that grabs a template or best practice intended for much larger systems.  We see this when a student comes out of college into the real world and has a bad habit of including unneeded programming concepts.  It is almost like a Golden Hammer or Boat Anchor situation.  Instead of code or a product being treated as the perfect fit, this time the culprits are design concepts.  For example, designing for flexibility that will never be used.  We see this when a system is designed to plug-and-play with the database back end yet there will never be any database used outside of the original decision.  We do not need to create flexibility when it is not used. Understand The Cost All design decisions include trade-offs.  Think about it for a minute.  A hard-coded, brute force solution is almost always going to be the fastest one.  There is less for the computer to process.  A simple example may help. Let's think about a program to add 3 to 5 and print out the result.  In pseudocode you can probably write it like this: output(3+5) The computer will parse the expression (3+5), execute it and print out the result.  A prettier, but slower example might look like this: Function outputSum (x, y) { z = x + y output(z) return } x = 3 y = 5 outputSum(x, y) While both approaches give you the results, one is faster to write and execute.  If you do not need to use that "outputSum" function anywhere else, then why write it?  This thought process is exactly the one we need to avoid a poltergeist.  While we ask ourselves whether a block of source that is repeated should be abstracted to a method or function, there also should be a question whether a method is needed if it only is called once.

Sometimes ideas that are good at one time become horrible later on.  This is one of many ways to get stuck in the boat anchor anti-pattern.  It is a situation that is well-described by the anti-pattern name.  We find ourselves dragging along a product or code that is doing little other than slowing us down. Defining the Continuous Obsolescence Anti-Pattern Although it may be bad form, I found a good definition of this anti-pattern on a site covering the anti-pattern much like we are here. [Click Here to See The Page] "A Boat Anchor is a programming anti-pattern that occurs when a part of a system is kept in that system despite it no longer having any use.  Generally this is because of developer belief (or prior experience) that they'll need it later. This belief is almost always wrong." The only correction I would add to this definition is that this has more reasons than simply developer belief.  Sometimes there are political reasons for a boat anchor or even momentum that makes replacing it difficult. Cut...It...Out. The fastest way to eliminate the drag from an anchor is to cut the rope tying you to it.  However, that is not always a feasible solution.  There are political reasons to keep that anchor around (eg. the CEO loves the boat anchor product) or we might have just enough usefulness left in the anchor to keep us from jettisoning it. Nevertheless, our best solution is going to be the simplest one.  When you find yourself dealing with this anti-pattern the best approach is to design it out of the picture ASAP.  By definition, the cost of keeping this thing around is growing over time.  It is a bad investment so do not keep throwing good resources away with the bad. Surprise! It's a Boat Anchor The scary thing about the boat anchor is that it does not always look like one early on.  That is the lure that gets us into this situation.  There is a good solution available that we embrace and down the road, it becomes aged and something that needs to be replaced.  This can happen with any framework or product.  Therefore, we can avoid this anti-pattern by designing our solutions with ways to avoid vendor lock-in.  Look into things like loose coupling and pluggable patterns to leave yourself an out when good products go bad.

As hard it is to spell the Continuous Obsolescence anti-pattern is easy to fall into.  The lure of shiny new versions of products often leads us into this trap.  We want to stay current with the latest features.  However, the cost of keeping up-to-date can put us in a pattern of upgrades over enhancements. Defining the Continuous Obsolescence Anti-Pattern The wiki c2 site provides a beautiful, pessimistic view of this particular anti-pattern. [Click Here to See The Page] "Continuous Obsolescence: This is the hardest Anti-Pattern to overcome. Corporations have their pet system that they mutate every time a new computer language and/or buzz-word builder comes down the pike to the developers. As soon as the pet system is migrated into the new language and/or method it becomes obsolete and thereby cancels any possibility of developers receiving a bonus for bringing the design in on time. It is also used to justify corporate heads existence by moving the blame for a poorly designed system to a new language and/or method of construction." This paints a depressing picture of this anti-pattern where it is almost intentional in its appearance.  I think the definition points more to planned obsolescence than continuous.  However, it does provide a synopsis that should make anyone want to avoid it.  If you are thinking that it feels a lot like being in quicksand, then you see why this is an anti-pattern. SAAS - A Silver Bullet? Software as a service is often the best way to avoid this anti-pattern.  The updates will come as frequently as a vendor desires.  However, you will have the cost of upgrades carried by the vendor instead of on your team.  This is not a perfect solution, but it comes pretty close.  Most SAAS vendors find it far too costly to their bottom line to make significant changes that impact the productivity of their customers.  While that does not tend to help developers that are using the latest frameworks, it does reduce or remove third-party integration headaches. Draw a Line In The Sand While Continuous Obsolescence is almost a given in the fast-moving IT world, there are still ways to avoid it.  The best is to define a development environment and freeze it.  I have seen this done to the point of downloading the binaries required to do the development.  That means there is no need to worry about something being unsupported or hard to find.  You select the tools and version when you start implementation.  Then you march forward with those resources.  Ignore updates as much as possible.  This will at least help you stabilize that moving target that a Continuous Obsolescence anti-pattern creates. 

The spaghetti code anti-pattern is one that has become less prevalent in applications.  However, we can still see some excellent examples in the world of scripting and other less structured code.  This anti-pattern typically comes out of short cuts and slapping together a solution.  That makes it easy to avoid.  The cost of repairing this anti-pattern makes avoiding it completely worthwhile. Defining the Spaghetti Code Anti-Pattern I am not often a fan of using the Urban Dictionary to find definitions.   Nevertheless, it has an excellent summary of this anti-pattern. [Click Here to See The Page] "In computer programming, code which flagrantly violates the principles of structured, procedural programming. Usually this means using lots of GOTO statements (or their equivalent in whatever language is being used) - hence the term, which suggests the tangled and arbitrary nature of the program flow. Spaghetti code is almost impossible to debug and maintain, and rarely works well. Programmers who write spaghetti code usually learned to code in an unstructured language such as BASIC, and never bothered to update their technical knowledge when they progressed to more serious languages." There is a lot to unpack in this definition, and it points to warning signs.  The essential points to absorb are the cost of repairing spaghetti code and its source in unstructured languages.  Professional developers should progress away from this anti-pattern early in their career.  If not, then you need to work on structured code ASAP to become a developer (the "better" qualifier can come later). Quick and Dirty We all understand the cost in quality of any task done in a quick and dirty manner.  However, the price of working with spaghetti code can be high enough to ruin the application.  I have seen a tangled mess that is almost impossible to maintain and extend.  Thus, the only fix, at that point, is to start from scratch.  It takes less time to rebuild the solution than to understand and modify it. Technical Debt It is hard to avoid situations where there is a need to put together a quick and dirty solution.  That alone is not going to create this anti-pattern.  However, when you let technical debt build up, it can become out of control.  You might be going down the path to this particular anti-pattern.  Fortunately, this is easy to avoid.  Include code reviews, regular attention to technical debt, and time to design your tasks.  These simple steps will make it easy to avoid getting a bad taste in your mouth from this anti-pattern.