Develpreneur: Become a Better Developer and Entrepreneur

The throw it over the wall anti-pattern is shared across a broad range of disciplines. However, it is particularly damaging to the software development process. We will focus on that discipline as we dig deeper into this communication-related issue. Defining the Throw It Over The Wall Anti-Pattern The Sourcemaking site provides an excellent setup for this anti-pattern. Thus, we will start there instead of our typical definition approach. [Click Here to See The Page] "Rarely is documentation entirely self-explanatory, yet understanding the vision and insight of the authors is an essential part of understanding the documentation. This is especially true of guideline documents, where there is an implicit assumption of independent decision making. This assumption also implies an in-depth knowledge of the authors' intent." Communication is where we see a breakdown with this anti-pattern. While assumptions can lead us into this situation, it often is just a lack of being thorough. Even worse, there usually is a culture that lacks respect for those on the other side of the wall. This environment not only suffers from the anti-pattern, it is also one that kills morale and teamwork. It All Comes Back To Why There are numerous issues that arise with this pattern. However, the most glaring (and damaging) is that it avoids communicating the "why" of a solution throughout the team. The point where documentation is thrown over the wall is the death of the "why." That leaves subsequent teams without the ability to do more than they are told. They will not be able to contribute to the solution outside of being a labor pool. In the highly competitive modern business world, any resource that is not being fully utilized can make the difference between success and failure. Trust your teams with context and clarification. This approach empowers them to make a difference above and beyond their work effort. A Downward Spiral While there are many other reasons to avoid this anti-pattern, productivity may be the easiest to measure. When content is thrown over the wall, it loses context. That means that downstream resources have to ask questions by throwing it back over the wall. This back and forth cycle can quickly add a lot of time to the project. That time can be the difference between "on time and on budget" or blowing past those milestones.

The "Analysis Paralysis" anti-pattern may be the most well known. It has a few other names. However, a search on this one will return a broad range of results. The detrimental effects of thinking over action are not seen only in software development. They make an appearance universally. Defining the Analysis Paralysis Anti-Pattern This time our definition is more of a description. The linked article provides a lot of reasons to avoid this anti-pattern. [Click Here to See The Page] "Delaying action while over-analyzing information clearly doesn't help when it comes to getting things done. In fact, a 2010 LexisNexis survey showed that, on average, employees spend more than half their workdays receiving and managing information rather than using it to do their jobs!" We have covered the value of analyzing, considering, and design throughout this season. Thus, the idea of analyzing alone is not an anti-pattern. There is nothing to be gained by charging into something without forethought. Therefore, we have an example of extremes being harmful and moderation the best approach. Too much or too little time spent analyzing your situation can be detrimental. Finding a Proper Balance I like to think of analyzing a problem as similar to a trip to a museum. The goal of the trip is to see all of the artwork. The best path through the museum is one that allows you to see each item once and only once. When we are analyzing a problem, there is a similar need. We want to address every point and facet of the problem (within reason, more on that later) without spending too much time on any given item. When we find ourselves re-analyzing an item, then we are likely going too far. Reasonable Analysis I mentioned the idea of considering every facet of a problem within reason. This is worth further discussion. Every problem includes knowns. There are facets we can accept related to a problem. These include environmental standards, foundational knowledge, constraints, and other attributes. There is no need to re-invent the wheel for these items. That is another anti-pattern. The key to determining what is reasonable brings us back to what is essential. When we know the "why" for solving a problem, then it will allow us to ignore some items. They are not pertinent to our "why" and not needed for a suitable solution. This ability to ignore attributes of a solution can be crucial. For example, speed may not be a factor or even quality. Sometimes an answer of any kind is better than the nothing that we have.

The mushroom management anti-pattern is one that appears everywhere. While it can be simplified to keeping employees in the dark, there is more to it. The side effects of this anti-pattern can cause long-lasting problems and even prevent a company from success. Let's look at it from the software development point-of-view. Defining the Mushroom Management Anti-Pattern The simple definition provided by Wikipedia gives us an excellent starting point for discussing this anti-pattern. [Click Here to See The Page] "Mushroom management is a style of management in which the personnel are not familiar with the ideas or the general state of the company, and are given work without knowing the purpose of this work, in contrast with open-book management. " I love this definition because it highlights one of our favorite topics. This implies the value of knowing the "why" for your work, even at an enterprise level. Confusingly, this is not a surprise to anyone. The reason behind things like vision and mission statements is communicating a corporate "why" to employees and customers. Why stop there? It only makes sense to carry that sharing of why things are done down to the lowest levels. When it is then you by definition are building the culture into everything a company does. Need To Know If you have ever talked to people that work in highly secretive situations, then you have heard about the challenges those environments create. This approach can even lead to the left hand, not knowing what the right is doing. While that may be required to protect some projects, it should be avoided where possible. There may be a sense of power in being able to keep knowledge from the staff, but that is detrimental to a team approach. It implies that team members or staff are somehow not worthy or capable of knowing completely the problems they are solving. I can not see how trust and loyalty will ever grow in such an environment. Trust Your Staff While there are many problems this anti-pattern creates, the most damaging is the lack of using your team. A lack of information about a problem prevents team members from using their experience and skills to address the problem fully. They do not have the context to bring all of their abilities to bear. For example, we can look at the idea of driving a nail into a board. When all the worker is told is to hit the nail with a hammer, then they will hit it once and maybe without the best amount of power. There is no context to allow them to use their nail driving skills. Now, let them know they are to drive the nail into a board and that it is best to do so until the nail head is flush with the surface. In this case, the worker can use previous hammering experience to take the best number of swings and proper force to complete the job. Better yet, they will not just finish it, but do so faster and better than if you have to talk them through it blow-by-blow.

Feature creep is one of the most prevalent anti-patterns in my experience. I personally find it a recurring challenge to avoid. The issue is that we can always find features that are nice to have with our solution. That makes them very attractive to tack on to our release or version. There is also a limit to what can be called feature creep. Let's look a little deeper into this one. Defining the Feature Creep Anti-Pattern Scope creep is incredibly common as an anti-pattern, and Wikipedia gives a helpful, concise definition. [Click Here to See The Page] "Feature creep is the excessive ongoing expansion or addition of new features in a product,[1] especially in computer software, videogames and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design." Notice the modifiers in the text above. When you see words like excessive, it always begs the question of what that means. Unfortunately, scope creep is a sort of dark art. We want to strike a balance between adding features that are worth the cost without blowing past target dates. This brings us back to the challenge of knowing when to declare victory. However, with feature creep, we can get ourselves into a situation where we are forced to go forward instead of cutting scope. Less Is More The way to beat this anti-pattern is to focus on the truism that something is better than nothing. Thus, a product with fewer features is better than one waiting for one with more features. There is always a minimum viable product that needs to be released. However, the challenge arises when you add to that MVP. The ROI for additional features can be tricky to calculate. The complexity is that it is not an either-or situation. It is often a now-or-later decision to be made. That is where I find we can best argue for or against a scope change. The decision comes down to whether we need the feature now and cannot wait until later. Unintended Consequences All scope creep is not an instance of this anti-pattern. There are changes we can make that are done so in an intentional manner with the trade-offs duly considered. However, any change should be drilled into to ensure the costs are appropriately measured. There are all sorts of side effects that even small changes can trigger. The best way to approach any change is to have a template of things that are potentially impacted by a change and use that as a checklist. If you miss something, then add it to the list for the next time. Here are a few to start you off. Testing Documentation Application Flow Additional/Changing Security Requirements Data models and Back-End Impact Application Performance End User Cost This is not a comprehensive list, so spend some time thinking about the impact you have seen changes make. If you do this regularly, then you may find the feature creep anti-pattern to be one that fades into the distance.

The magic strings anti-pattern implies a much more entertaining experience than it is. This coding style is not rare. Thus, it is likely you have encountered it or even fallen into this trap. As always, proven design principles and best practices help. However, the reasons this is an anti-pattern are worth reviewing. Defining the Magic Strings Anti-Pattern The DevIQ definition for the magic strings anti-pattern provides an excellent discussion of the cons of this approach. [Click Here to See The Page] "Magic strings are string values that are specified directly within application code that have an impact on the application's behavior. Frequently, such strings will end up being duplicated within the system, and since they cannot automatically be updated using refactoring tools, they become a common source of bugs when changes are made to some strings but not others. " The first sentence gives us a brief definition, and I like how it dives right into the problems this causes. The challenge with this anti-pattern is that it is so easy to fall into it. There are some reasons we might think that we can get away with a magic number. It is best to avoid these temptations. The sanity you save may be your own. Clever Is Not A Best Practice I have had arguments over the years about magic numbers. There are all sorts of discussions about speed, performance, clever solutions, and more. The thing is, none of that matters. The anti-pattern can drive you nuts and reduce quality dramatically. Consider a situation where you have to change a magic number. You have no way to determine how often or where it is used in the code. That alone could lead to weeks or months of tracking down outlier bugs caused by the number change. Even worse, the update could lead to data corruption if you miss a couple of usages in the code. Always fall on the side of more straightforward code over saving a process cycle or two. Fixes Are Hard The example provided above is also why this is so hard to recover from. First, you have to realize there are magic numbers in use. Then, you have to track down where they are used. You might even have to figure out what they mean and why they are there. Nothing good can come from that. We have looked at a lot of anti-patterns. However, this may be the most insidious one yet. It is incredibly easy to fall into and almost impossible to correct.

The death march anti-pattern is one of the most painful to endure. There is even a tendency to envy those involved in actual ones. This situation crushes morale and feels like it will never end. Defining the Death March Anti-Pattern This anti-patten is so common we can go to Wikipedia for a good definition. [Click Here to See The Page] "In project management, a death march is a project that the participants feel is destined to fail, or that requires a stretch of unsustainable overwork. The general feel of the project reflects that of an actual death march because project members are forced to continue the project by their superiors against their better judgment." I think the key here is the word "unsustainable." There are projects that run a long time and burn a lot of hours but are almost pleasant to work through. The most significant difference is where one feels destined to fail. In a good situation, it feels like the team is moving to a big victory. Thus, a project becomes demoralizing to part of the group. On the other hand, it is worthy of the effort to others. This is rarely the case. A typical death march sucks everyone into the abyss, and thus, failure seems inevitable. It Is A Project Management Problem Note that the perception of the team is the driving reason for determining the existence of this anti-pattern. The product or solution is often unrelated to this anti-pattern. The best project in the world can become a death march through mismanagement. On the other hand, even horrible projects can go smoothly and keep morale high. Key Indicators It can be seen as a flippant answer. However, the action of considering whether a project is a death march is a leading indicator that you have found one. In this case, the time spent considering whether you are in a death march is proportional to the likelihood that you are. Communication and clearly defined goals are also indicators. When you see a project floundering to keep members informed or goals are regularly changed, you probably have the anti-pattern. If anything is a perfect illustration of this anti-pattern, it is a downward spiral. This is not always the case. However, many of these situations include some example of running in circles. Thus, a lot of effort results in no progress.

In this episode, we cover another anti-pattern that everyone has experienced. However, the CYA approach is not often seen as something to avoid. There are downsides to the cover your assets approach that need to be seen for what they are so our use of it is tempered. Defining the Cover Your Assets Anti-Pattern The Antipatterns.com site has a short and sweet definition of this anti-pattern for us. [Click Here to See The Page] "Document driven software processes often employ authors who list alternatives instead of making decisions." This definition provides us something close to analysis paralysis but from a different starting point. There are many reasons why we stumble into this anti-pattern. It can be to provide plenty of information for a decision. On the other hand, it can show our lack of desire in making a choice. The anti-pattern arises when our goal is to make a decision, communicate it, and move forward. Too much information about the decision process can be a waste of time. Even worse, it can confuse the reader as to what decision was made. Clear and Concise When you are tasked with making a decision and communicating it, the KISS method is best. Keep it simple. Declare the decision, state it clearly, then add color and commentary only if necessary. Your audience may desire more information. However, there should be other ways to find that content. Do not confuse the answer by providing a reason for the same. Think of it as the reader asking the question, "What did you decide?" Answer the question directly instead of boring or confusing them with a dissertation. A Time and A Place There are plenty of vehicles for communicating the how and why of a decision. SDLC documents are not those vehicles. The assumption we make in reading design and implementation documents is that the decisions were made with a proper amount of research and thought. The reader is not going to assume you decided in a vacuum or without forethought. Thus, there is no need to defend it in these documents. Let them know the decision. Then, they can focus on getting it implemented.

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.