Develpreneur: Become a Better Developer and Entrepreneur

We have marched through 31 examples during this antipattern season.  Therefore, we have enough of them to step back and look at themes, bad habits, and commonalities.  While it is helpful to know about the individual patterns, it is better to see the big picture approaches we should avoid.  Let's get to beating some dead horses. Communication Is Key We can do everything right and still end up down a dark hole if we fail to communicate.  This recommendation involves vertical communication among staff and management as well as horizontal across roles.  We also want to be sure that we have made context and our "why" clear as part of the communication.  Provide a good map and give it to the team.  If you fail to create a good map or fail to give it to the team then the destination they arrive at may be surprising. Embrace Change The modern business world moves fast and changes often.  IT is at the forefront of this controlled chaos.  Thus, you need to plan for change and be ready to adjust as often as needed.  That requires our plans to be flexible, but also our tools and processes.  The perfect tool for our current project may be practically useless for the next one.  We want to learn from our experiences without getting tied tightly to them. Smell The Roses While smelling the roses does not help our productivity, stopping and considering our path does.  We all want to get the solution out the door as fast as possible.  However, the phrase about fools rushing in is very pertinent to our work.  When we dive in without design and thinking through a solution we are far more likely to end up spinning our wheels.  There are always dead ends and rabbit trails we can wander down.  The time lost by these can be reduced with some time sent planning our approach to implementation even down to a detailed level.  Therefore, things like pseudo-coding can be very valuable.  Use this antipattern season to embrace new habits and become a better developer. If nothing else, take a look back at the anti-patterns we have covered.

Death by planning is an anti-pattern that makes us look like lemmings.  We make a plan, and then we follow it mindlessly.  This approach can work for some projects like building a house.  However, software development does not work this way.  There are always changes and unknowns that we encounter during the SDLC process.  Thus, we want to be able to adjust to those instead of staying rigidly to the initial course. Defining the Death By Planning Anti-Pattern The Sourcemaking site provides the definition we will use for this episode.  It is lengthy, but this anti-pattern calls for that. [Click Here to See The Page] "In many organizational cultures, detailed planning is an assumed activity for any project. This assumption is appropriate for manufacturing activities and many other types of projects, but not necessarily for many software projects, which contain many unknowns and chaotic activities by their very nature. Death by Planning occurs when detailed plans for software projects are taken too seriously." The primary factor in this anti-pattern is that last sentence.  We gain value from creating detailed plans.  However, they should be taken with a grain of salt.  We often run into situations that are much like a battle where all the plans are thrown out after the first shot is fired.  It is rarely that dire, but software development should no more be a slave to design than an army is to a battle plan. It Is Not Entirely Academic One of the common arguments from those that follow this anti-pattern is the design is the "right" way to proceed.  The idea is that the time put into planning needs to be respected and veering from that course will invalidate the plan.  This mindset often comes from an academic environment where the process is considered the critical thing to focus on.  Once we get into the implementation phase of the SDLC, the solution is the key thing.  The process is there to help us, not shackle us. If a Process Occurs And No One Notices... While it may be tempting to skip the design and related processes, that is not the solution to this anti-pattern.  Death by planning is not a problem because of the planning part.  It is a bad practice when you focus too much on the plan.  This is not very different from most things in life.  Things are best when done in moderation.  Too much of anything throws off the balance.  In this case, it is worse because of planning being a secondary part of the life cycle.  The goal should always be building a solution.  Every other best practice is there to help us achieve that primary goal.  Therefore, rules (and even design decisions) are made to be broken.

The fire drill anti-pattern is one that falls on project management.  While we can personally place ourselves in this sort of situation, the anti-pattern comes from planning.  To be specific, it comes from poor planning.  Think of the idea that we can cram for a test the night before and extend it to slamming home a project at the last minute. Defining the Fire Drill Anti-Pattern The definition for this anti-pattern has been selected from the anti-pattern site.  IT provides a bleak picture of the pattern that is also a common root cause. [Click Here to See The Page] "Management waits until the last possible moment to allow developers to proceed with design and implementation; then they want results almost immediately." The above definition oversimplifies the ways this anti-pattern can appear.  Yes, this can come from blocking design or implementation.  However, it can arise from systemic blockers of any kind.  Thus, specific requirements or constraints may not be resolved until the last minute, and then the deadline is unreasonable.  We may even see this occur when a demo goes "too good."  This happens when the hacked together demo we showed management is seen as almost done, which leads to unrealistic deadlines. Setting The Pace The best way to avoid this anti-pattern is to set milestones and push high-risk items to the front end of the plan.  When we take this approach, we will have tasks defined that require a "push" to hit those deadlines.  Instead of one big push, we reduce stress by setting up smaller pushes on a regular basis.  That reduces the dead periods as well as lowering the peaks.  When this is done to perfection, we get a straight and level line for the development effort. Just In Time Development The modern business world is full of just-in-time this or that.  A fire drill can be avoided by doing this with your SDLC process.  Part of the design and requirements steps should be a definition of prerequisites.  These will help you lay out deadlines for tasks in a way that helps the team avoid bottlenecks.  For example, the user experience design should be complete before the user interface is implemented.  When it is not, the implementation will stall until that design is done and communicated.  There are numerous situations like this during the creation of a solution.  However, when they are identified early on, they provide a roadmap that can help create some smooth sailing.

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.