Develpreneur: Become a Better Developer and Entrepreneur

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.

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.