Develpreneur: Become a Better Developer and Entrepreneur

This anti-pattern implies a heavier hand than is common.  While the intellectual violence anti-pattern sounds shocking and over-the-top, it is common and often subtle.  We have many ways of shutting down discussion or "protecting our turf" that are easy to miss. Defining the Intellectual Violence Anti-Pattern The Sourcemaking site has a good definition and discussion about this anti-pattern.  They also focus on the primary issue with this anti-pattern. [Click Here to See The Page] "Intellectual Violence occurs when someone who understands a theory, technology, or buzzword uses this knowledge to intimidate others in a meeting situation. This may happen inadvertently due to the normal reticence of technical people to expose their ignorance." That primary issue I mentioned is that it puts a damper on a discussion.  The general results from this anti-pattern are fewer questions and review of statements in a meeting.  This has a wide range of symptoms including the classics like, "that's how we have always done it" and "everyone knows that." Question Everything The best way to avoid this anti-pattern is to create an environment (or culture) that embraces questions.  Destroy any sacred cows and have no fear of rebuilding them as needed.  We see this sort of environment in the solution to other anti-patterns as well.  The world is changing every day so it is short-sighted to think that what we know today will hold true next year (or even tomorrow).  While intellectual violence can be traced back to other reasons, (like job security and fear of having ignorance shown) a culture of feedback and discussion will overcome those as well. The Tip of The Iceberg Intellectual violence as an anti-pattern is worth digging into when it appears.  There are other issues that may be behind this approach.  They may be individual issues such as worries of job security or enterprise level problems of respect in the workplace.  All of those are valuable issues to be aware of and address.  It can make your team happier and improve morale.  When that happens you will not only stop intellectual violence now, you will likely squash it in the future as well.

It is hard to go through life without being warned against reinventing the wheel at some point.  This recommendation is a general warning to avoid duplicating effort where possible.  Thus, we have an easy to understand anti-pattern.  On the other hand, we should look deeper to determine whether we are avoiding an anti-pattern. Defining the Reinventing The Wheel Anti-Pattern The DevIQ site has a simple definition and problem description that serve as an excellent basis for our discussion. [Click Here to See The Page] "It’s common for software developers and some organizations to prefer to write something they may need for a given project themselves, rather than using an available open source or commercial offering.  Generally, it’s best to avoid this urge unless the feature or tool in question is a core part of the product being delivered." Note the use of the word "generally" at the start of that second sentence.  There are some great reasons to tackle a problem from scratch instead of going with known solutions.  You might even be avoiding the related "reinventing the square wheel" anti-pattern where someone starts with a broken solution and tries to fix it. Have a Reason With strong reasons for and against reinventing the wheel, there should be an intentional approach to implementation.  The first step is to recognize what has been done before.  Once you have noted those situations, then proceed to decide whether or not you should use those solutions.  The easiest way to avoid this as an anti-pattern is to have a good reason for the approach you selected. Lost Opportunities A lot of developers lean towards reinventing the wheel as opposed to re-using the work of others.  They recite reasons to avoid using that prior solution along the lines of time to ramp-up or understand the work of others.  While these may be valid reasons, the value of reuse should not be glossed over.  Simple things like testing and quality are profoundly impacted by starting from scratch.  Instead, use a solution others created and tested.  Gain from their experience and efforts.  There is also an often underestimated value of using solutions that have been tested in multiple environments and contexts.  There more you stretch a solution and validate it, the higher the quality it has in any situation.

A swiss army knife is a great tool to carry around with you.  However, this anti-pattern tells us that building a one-stop-shop for your design functionality is a wrong approach.  Several problems arise when you throw almost everything into a single class. Defining the Swiss Army Knife Anti-Pattern I found a good blog post on this anti-pattern to provide our definition.  The article focuses on an interface, but it holds for a class in general as well. [Click Here to See The Page] "Swiss Army Knife Interface is an interface class which has excessive number of method definitions. Architect/designer may design this interface to use for every need of the software, but this is a wrong approach and an antipattern. More than one interface must be designed using some design approaches." We stumble onto the idea of what is a proper number of methods for an interface or class.  Unfortunately, this is not a hard and fast rule.  It is something that varies by situation.  Thus, "too much" is left up to the designer and not a single number or even range, although 7-10 seems like a comfortable range for most people. Design First, Then Code It may feel like we have gone down this path before.  And we have.  Many anti-patterns, including the swiss army knife, can be avoided with design and planning before you dive into implementation.  However, in this case, there needs to be an on-going habit of designing before coding.  When you skip that step, you can find yourself building a solution that grows ever closer to this anti-pattern. Easy To Miss The toughest challenge with this situation is stepping back and seeing it approaching.  It is far easier to tack on function after function without keeping the big picture in mind.  When you stay in the weeds too much, it is easy to overlook the swiss army knife you have created.

While experience is an excellent teacher, it is not a silver bullet.  Every problem we tackle is a little different.  Thus, we should follow best practices even when we think we have done this all before.  When we instead believe we can take short-cuts, we are likely to be practicing architecture by implication. Defining the Architecture By Implication Anti-Pattern We go with a lengthy definition this time around.  I recommend you check out the whole page for even more details about this problem. [Click Here to See The Page] "This AntiPattern is characterized by the lack of architecture specifications for a system under development. Usually, the architects responsible for the project are experienced with previous system construction, and assume that documentation is unnecessary due to their competence and experience. This overconfidence leads to exacerbated risks in key areas affecting system success." This is definitely an architecture level anti-pattern.  You will not even recognize it unless you have worked on multiple projects.  Fortunately, you will also not be susceptible to it.  In those case, you may make architectural mistakes, but they will be due to lack of experience, not ignoring what experience taught you. Address Past Mistakes Experience teaches us what to do to be successful.  However, it also shows us traps and mistakes to avoid.  If we lean only on the things that lead to success, then it is architecture by implication.  Think of it as a "gimmee" in golf or a related sport.  The implied assumption is that the task is so simple it cannot be done wrong.  The mere idea of anything in system development being this simple should have you on the floor laughing.   I Know This The three words above should always be a warning sign to you.  When you look at a spec or requirements and estimate based on prior knowledge, you may miss an essential factor.  Treat each task or module as unique.  You should be able to ask good questions and verify assumptions quickly.  Nevertheless, that procedure must still be completed to avoid missing a twist this latest project requires.

The skills of writing code and abstracting functionality are not the same.  This fact is why the Grand old Duke of York is an anti-pattern.  Passing around essential tasks like design is not a practical approach.  We should set up a team, so the people that are best at a job are the ones doing it. Defining the Grand Old Duke of York Anti-Pattern This particular pattern is not easy to define.  Instead, we will jump right to the problem in setting the stage for this anti-pattern. [Click Here to See The Page] "Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists and their counterparts (whom we call implementationists) Abstractionists are comfortable discussing software design concepts without delving into implementation details." There are several reasons why a team falls into this anti-pattern.  They can be small and ask more of the implementation team than normal.  They can assume developers are abstraction experts or some combination of these two.  In the worst case, the idea of abstraction never occurs to the team. Assigning Roles This anti-pattern boils down to a general case of putting team members in a position for success.  Use them for their strengths instead of just throwing them at a problem.  When you take this approach, the team will work better, have higher morale, and produce solutions with higher quality.  Look at it simply.  People are going to have a higher success rate doing things they are good at. IT Roles Are Not The Same We started the definition of this anti-pattern focused on design (abstraction) vs. coding (implementation).  It is not always clear that there are nuances to IT work.  Development is not the same as design, which is not the same as testing.  These are different skills, and people will have differing aptitudes for each.  Consider the strengths and weaknesses of team members as roles reassigned.  When you do, the team will be happier and more productive.  They might even produce a superior product. 

There is an old saw about too many cooks spoiling the broth.  This statement roughly describes the design by committee anti-pattern.  While two heads may be better than one for most problems, there is a diminishing return as we add more "heads" to the mix.  At its worst, we end up with a design by committee situation. Defining the Design By Committee Anti-Pattern The comments on the definition at the WhatIs.com site provides some excellent food for thought on this anti-pattern. [Click Here to See The Page] "Design by committee is a term sometimes used to describe a design that is flawed because too many people provided input. The phrase implies a lack of a coherent vision and, perhaps as a result, a failure to successfully solve the problems the design was intended to solve." We cover a few different reasons why this situation is an anti-pattern.  However, the essential problem with this approach is the lack of a coherent vision.  Think of a tug-of-war.  When everyone pulls the same way, you will gain strength with numbers.  On the other hand, the more people that pull in different directions, the harder it will be to win the match. Velocity The first concern often mentioned with design by committee is the speed of making decisions.  A larger team requires more time for everyone to voice their opinion and gather vote results.  A small group will always have the ability to be more agile.  The lower number allows everyone to be fully invested in the decision, make it, and then move to implement. Diffusion of Expertise In my mind, the most critical weakness of this approach is what I call the diffusion of expertise.  If the group provides solutions that are an average of the intelligence of the members, then some people are dragging down that number.  In a practical sense, the group may water down its expertise by finding ways to compromise on decisions.  This can arise when the less popular choice (or opinion of a singular expert) is ignored or watered down in a desire to play to the politics of the group.  Instead of driving to get it right, there is a drive to get an acceptable solution.  Once that situation arises, the result will be less than ideal.

We all know that more is always better except when it is not.  The challenge of quality and quantity is a common anti-pattern for software development.  We take a look at it in this episode about the warm bodies approach. Defining the Warm Bodies Anti-Pattern There are several definitions of this anti-pattern.  In this episode, we use the Daxx site definition to drive our discussion. [Click Here to See The Page] "This antipattern seems, at first, to have more to do with the structure of your company than the structure of your software. That being said, problems with the former can have unfortunate consequences for the latter. “Warm bodies” are people who work for your company, but aren’t deeply invested in its success." This anti-pattern is one that we all run into in our career.  It is almost unavoidable.  Larger teams are also going to increase the odds of it happening.  While this can be a concern, it seems unrealistic to expect that every team member is a "true believer" in the project.  The most likely solution is to keep your team small.  However, that is not going to guarantee you avoid the warm bodies situation. A Leadership Issue Building a team that does not suffer from warm bodies starts with hiring.  However, the leadership of the group is essential to maintaining this over time.  The worst case is when a dedicated team loses its drive and focus.  This is not a place to cover effective management skills, but we can look at a few warning signs of a team adrift.  When meetings are being skipped or cut short, there might be a problem.  These actions can come from a team that is focusing on implementation, but more often, it comes from "having something better to do."  While this is understandable at times when it becomes a typical response, then dedication should be addressed.  Set clear priorities and have a mechanism for accountability to make it apparent when things are going off the rails. Garbage In - Garbage Out Now let's back up to the building of the team stage.  When you are growing your team, there should be questions related to focus and match.  Start with an idea of the ideal team member and then screen for those attributes.  Look for a desire to solve the core problem and a solid work ethic.  These traits will help you build a team that can survive the challenges ahead.

In an effort to re-use our previous work, we can over-simplify a solution.  One such situation is when we grow from a stand-alone system to a distributed one.  This particular anti-pattern is a facet of the autogenerated stovepipe.  Even the best solution in one case is not always going to be a good one to move to an enterprise or a distributed approach. Defining the Autogenerated Stovepipe Anti-Pattern There are several definitions of this anti-pattern.  In this episode, we use the source-making definition to drive our discussion. [Click Here to See The Page] "This AntiPattern occurs when migrating an existing software system to a distributed infrastructure. An Autogenerated Stovepipe arises when converting the existing software interfaces to distributed interfaces. If the same design is used for distributed computing, a number of problems emerge." I find this to be an almost obvious anti-pattern.  However, we do not always see the obvious implications of moving a solution to a different approach.  The good news is that we can often see what others have found in their similar attempts.  Thus, we can avoid an autogenerated stovepipe through abstraction and thorough design. New Environment,  New Problems One of the problems with trying to re-use code and designs is making sure they fit in a different paradigm.  A simple environment allows us to solve problems without getting overly complicated.  However, those more straightforward solutions may not scale to more complex environments.  Nevertheless, we do want to re-use code as often as possible.  With these conflicting goals in mind, we once again need to look to abstracting our functions and methods where possible.  This best practice is a perfect solution for our struggle.  Write code that is a good fit for the complexity you need to address.  This situation is precisely why we want to create code that can be extended or shifted to another implementation in the hierarchy. A Game Plan While many of the issues that may arise in a move from one environment to another are apparent, they can easily be missed.  Thus, it always helps to start these sort of "migrations" with some time considering the essential differences.  While this does not guarantee the process will be flawless, it does reduce the risk of surprises.  Those fundamental differences are valuable in mapping out the extensions and enhancements your new solution will need.  These will allow you to take advantage of the existing one.

We often look at vendors and standards for a way to improve productivity.  There is nothing wrong with this and it even is a best practice.  However, not everyone follows a standard entirely or even in the same way.  This situation can lead you to a wolf ticket antipattern.  In short, the product you choose is not what it seems. Defining the Wolf Ticket AntiPattern I find the origin of this anti-pattern name to be instrumental in defining it. [Click Here to See The Page] "The term wolf ticket originates from popular slang. In slang, a wolf ticket is an unofficially issued event pass (e.g. for a rock concert) that is sold by unscrupulous ticket scalpers." An essential piece of this situation is the idea that there is a demand for a product.  This desire combines with a willingness to sell into that demand to give the wolf ticket antipattern.  While blame can be pointed at the "scalpers," it is also the fault of those that are open to taking a shady route to their destination.  We see this often in the world of IT.  New technology becomes available, and then we all rush to find the tools to help us become productive with it.  There is a value in being leading edge, but risk as well. Abstract Always We often refer to abstraction as a way to avoid anti-patterns.  This case is no different.  We can reduce the risk of a wolf ticket by working with proven technology and stable standards.  However, that is not always feasible or even the best solution.  Instead of trying to avoid the new and shiny, we can insulate ourselves with good design. Hedge Your Bet While an abstract design is always a best practice, you can also improve your odds by avoiding vendor lock-in.  Keep an eye out for the less settled areas of a standard.  It seems like this is always an option.  You will have some portion of the new technology that is core.  These areas are handled the same by every vendor.  On the other hand, there are edge areas that are less settled.  Avoid getting into those areas as long as possible in hopes that the deviations calm down.

In this episode, we tackle a higher form of the Spaghetti Code Anti-Pattern.  While that is a code-level issue, the jumble antipattern shows up in the architecture.  There are almost always going to be horizontal and vertical aspects of a design.  Some facets are specific to the solution while others are common across multiple applications.  When we confuse and tightly couple these aspects then it turns into a jumble. Defining the Jumble AntiPattern The C2 wiki makes another appearance as we look into a definition for this anti-pattern. [Click Here to See The Page] ""When horizontal and vertical design elements are intermixed, an unstable architecture results. Vertical design elements are dependent upon the individual application and specific software implementations. Horizontal design elements are those that are common across applications and specific implementations." The idea of vertical and horizontal components to a solution may seem like an academic discussion.  However, it is essential to be able to differentiate among them.  When you ignore that differentiation then you effectively remove your ability to re-use code. A good example is a simple validation class.  If you mix in the domain (application) specific functions with the general purpose ones then it becomes difficult to separate them.  That leads to a struggle when trying to re-use that code in another domain. I Need A Map One of the benefits of well-considered design (AKA not a jumble) is that others can easily find features they are seeking.  The less tested code that is domain specific will be in one place.  On the other hand, the higher quality re-used code will be elsewhere.  You then have a solution where the higher quality code is not going to get in your way while debugging.  Better yet, you will be able to easily pull out the code that can be re-used. Intentional Implementation The best way to avoid the jumble antipattern is to spend time on design.  This is a situation much like the idea "a place for everything and everything in its place."  When you are creating a method, function, or class then start by considering its aspect.  Is this specific to the current application or something you can re-use?  If it is likely to be re-usable then group it in with the other re-usable code.  Do not make it hard on the next developer to figure out what code has re-use potential.