Develpreneur: Become a Better Developer and Entrepreneur

We start season 17 with an overview of what to expect. This season will focus on using failures to gain success. Too much is made of the road to success without pointing out the learning that got someone there. The stories of this season will hopefully provide more examples of how a failure or mistake was just part of the journey to success. The Source Of Using Failures To Gain Success Scott Adams wrote a book called "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life" that narrates us through many missteps on his way to success. There is a chapter where he lists a lot of mistakes and some of substantial size. That is where I saw the topics for this season start to line up. So many situations could have been seen as only a setback instead of a stepping stone for later success. I think a positive attitude towards our challenges is in itself the key to success. Learn From Our Mistakes  It is common to hear about how we should learn from our mistakes. However, there are not enough specific examples in self-help books or other guides to success. While each of us has our strengths and weaknesses, there are many lessons learned that we can share. The goal for these episodes is to point out such situations and a "moral to the story" for each. These are not to the level of "Aesop's Fables" but are also more modern and specific in nature.

We end this season with a look at using patterns and anti-patterns throughout your work.  The value they provide is obvious and costs little.  We gain the lessons learned from others and have those available for our projects.  Those experiences are valuable to us and jumpstart our solutions. Using Patterns Patterns are just that.  They provide a recommended series of steps or an approach.  However, they are not the solution.  We need to use these tools as an outline or guide to building our specific solution.  That means we may need to add or subtract from a pattern to make the most of it.  Do not consider these to be hard and fast rules.  Rather, review them and determine where they can inform the solutions you are building. Avoiding Anti-Patterns I often think of anti-patterns as a slippery slope warning sign.  Just as everything about patterns is not all good, anti-patterns are not full of mistakes.  We often see that anti-patterns arise from the best of intentions or at least the goal of getting things done quickly.  We can make those trade-off decisions without falling into an anti-pattern.  On the other hand, the point of an anti-pattern is to warn us as to where a few small steps in a direction can lead to great strides.  Think of these as caution signs that make us aware of the danger ahead.  Avoid them if you can and be intentional about taking these steps when you do not have better options. Challenges Whether embracing patterns or avoiding anti-patterns, every problem is unique in some way.  Thus, we need to use these as suggestions and cautions.  We can easily fall into a trap when we take a general concept like patterns and force our solution into it.  Allow for tweaks and customizations as you use these for the greatest impact. At the end of the project, it is still your unique solution that is created.

The BHAG or Big Hairy Audacious Goals approach to vision or roadmaps is often recommended.  The objective is to keep from limiting ourselves.  The problem is that too much of a good thing can turn into a mental block or analysis paralysis.  Too many options or too many tasks to complete is often overwhelming. The Big Hairy Audacious Goals Anti-Pattern Defined This anti-pattern occurs when the focus is on the overall goals or scope rather than what is in front of you.  There is a difference between seeing a goal and being able to complete it today.  While people generally see that difference, it is not always made clear. That can lead to a sort of "are we there yet, are we there yet?" drumbeat.  Urgency has its uses.  However, there are times when it gets in the way.  This anti-pattern is just one example.  The problem is that we spend time planning out some grand strategy or reviewing all that needs to be done instead of actual work.  We end up concerned more about all we have to do instead of doing it. Avoiding The Anti-Pattern I often think the Alcoholics Anonymous approach of "one day at a time" is more of a life suggestion.  It also has a biblical root in the idea of each day has enough worry for itself.  Do not worry about tomorrow.  To be clear, that is not an admonition to only focus on the step in front of you.  However, there are times when we are looking too far ahead and stumble over something right in front of us.  This anti-pattern is best avoided by good estimations and communication.  We keep our focus short-term or tactical through most of the project.  That allows us to make steady progress and not get worried about how long the journey may be. For example, a tightrope walker needs only worry about the stem they are taking instead of how many more steps they need to cross the gap.  Our approach can be the same.  An attempt at embracing the whole project or scope can be daunting and install fear or stress.  We can avoid that and stay positive by taking smaller steps. Challenges The start of a project, in particular, can lead us to look at the overall plan.  All of those tasks and steps leave opportunities for missteps and mistakes.  All of that summed up risk is often worrisome and leads to mitigation strategies.  Too much focus on mitigation can leave us struggling to take the first step.  Furthermore, how much of that worry about risk will end up being useful?  If we take a proper step then worry about the misstep was somewhat misplaced.  As always, everything in moderation.

One of the most powerful and useful patterns I have come across is one we will call rinse and repeat.  It may also be seen as copy and paste or templates.  However, the result is a way to rapidly generate a lot of similar solutions within an architecture or system. The Rinse And Repeat Pattern Defined The essential piece of the rinse and repeat pattern is a similarity in approaching a series of problems.  This pattern becomes apparent when we solve a problem and then move on to another very close in its structure. For example, the classic almost anti-pattern of a class full of getters and setters can use this pattern.  You build a list of attributes, build out the getters and setters, then rinse and repeat across the other container objects. That is an elementary example of this pattern.  We re-use the similarities from solution to solution as a starting point, then customize.  The best part of this pattern is using a senior developer to solve the problem and then pass on the rinse and repeat portion to junior developers.  Thus, we get a high-quality solution quickly and cheaply.  Applying The Pattern The way to use this pattern is to isolate the areas that are the same from iteration to iteration.  Then set up a pattern for implementing the differences.  This may be a very rudimentary bit of work or could be something more complex like data mapping requiring business analysis.  The goal is to make the work easy to estimate and repeatable.  That allows us to tightly define the rinse and repeat actions while also understanding the effort typically involved.  We then can do the work or farm it out with our detailed requirements and deliverables easily shared. Challenges Similar but not equal can be a trap.  It is not uncommon for a rinse and repeat process to stumble across an outlier of some sort.  That outlier can cause a substantial change to the approach or solution and break the ability for someone to quickly produce another iteration of the solution.  The good news is that we still are not likely to do more work than would normally be required.  We just need to adjust our estimates for an unforeseen chuck of extra work.

Our new patterns include the rosetta stone.  This pattern provides a path to link disparate systems and their data formats.  It comes from the historical rosetta stone which was a multilingual text used to decipher ancient languages.  We use this as a sort of pathway to a common language for our application. The Rosetta Stone Pattern Defined Modern software often has multiple other systems that need to be integrated with.  That means we need to pass data back and forth.  The format and structure of the data we send can be challenging to map across multiple systems.  The rosetta stone pattern approaches this problem by designing a single format that all of our data will transform into or be exported from.  Thus, we always map to one set of data when pulling from other systems.  Likewise, we have one format we generate that other systems are provided.   That avoids us having to map from each disparate system to every other system.  We create a hub and spoke rather than a mesh network.  Therefore, we have a dramatically reduced number of integration points that need to be addressed.  Also, we have a set format to convert new systems into.  Applying The Pattern There are two main ways to apply this pattern.  One can either build a master format that combines the data from all of the desired integration systems or build what the solution needs as the master.  The latter approach tends to be better as it focuses on the solution rather than other systems.  We also are driving the format and structure instead of reacting to other systems.  Finally, we have a static universal format that does not change based on external factors. Challenges Data types and labels are always a challenge for this pattern.  Date-related fields in particular have a number of challenges including time zone mappings and a multitude of formats.  When the central structure is created it helps to make it as similar as possible to the external systems.  However, organizations and lines of businesses use that data in different ways and often have different views of the related labels. For example, take a field called "name."  That can be the name of many things and likely is helped by a qualifier.  The disparate systems may all have only one thing that is named in their data set while we have dozens.  The more external sets we have to inform our central creation, the better.

We continue on a series of new patterns and anti-patterns with "the worst that can happen."  This pattern uses fear and hyperbole to help us tighten up a design.  We imagine what can go wrong and use that as a guide for applying fixes, hooks, and exceptions.  Thus, this pattern is more a process than a pattern per se.  However, it is an important step we can take to validate and strengthen our solution. The Worst That Can Happen Pattern Defined The pattern is applied by reviewing an architectural design or component with the mindset of the worst that can happen.  Thus, we force ourselves to think outside the box and play our way through difficult scenarios.  Disaster recovery planning often uses this pattern. First, we look at the worst possible scenarios and the related costs.  Then we assess whether we need to build a circumvention mechanism or risk the scenario.  That last point is essential in our review. Of course, we can decide to ignore handling some situations because of a low cost, risk, or likelihood.  For example, the end of the world could happen.  However, we do not feel like that is something we want to handle among our exceptions. Applying The Pattern Applying this pattern is a challenge as it searches for variants from the "happy path" in our solution. First, we examine inputs and outputs with an eye toward how those can "break" or be missing.  Then, we plan a strategy for handling those problems.  The goal is to ensure we understand the risks and costs associated with our solution. Of course, there is always an option to push some of these issues into a backlog or a technical debt pile.  However, that at least makes them known quantities. Challenges This pattern can create rabbit holes to go down and get lost.  There is a cost-benefit to every potential problem, which must be considered.  When we fail to evaluate costs properly, we can end up with a never-ending list of special cases to address.  The end-of-the-world example is a way to view these.  When it looks like the cost of the worst that can happen is too much to overcome, then hope for the best.

The idea of technical debt is a hot topic among software development groups.  In particular, this concept shows up in agile efforts.  While it is more a concept than a pattern, we can use this as a pattern for our design and development work.  In fact, it lines up well with the Pareto principle and pushing details off until after delivery. The Technical Debt Pattern Defined I like to think of technical debt architecture as boxes and connections that are dotted lines.  We sometimes see a whole section of functionality surrounded by a dotted line fence.  These are referred to as future features or possibly optional.  These items are, in fact, technical debt in the design.  We are assuming they will be in that category before we even start on the solution.  The pattern can be handled through phases of implementation or the amorphous "future version" label. Applying The Pattern This pattern is easy to apply.  The designer or architect selects an item or items and designates them some form of future scope.  In Agile terminology, this is an assignment to the backlog.  The item(s) might even have some sort of special priority or designation to put them in a backlog that is pre-backlog in the process.  The term hold or ice is not uncommon for these items and implies how little with think of the priority.  While this approach can be a way to kick the can down the road, it is also a pattern for focusing on high-value features first.  These have less value by definition and we will get to them once the more important features are complete. Challenges Anytime we put an item on a backlog there is the danger it will never get brought back to be done.  Therefore, technical debt is almost an anti-pattern as well.  It can be a mechanism for sweeping features under the proverbial rug.  There must be ownership of these items and a push to ensure they do eventually bubble back up to be addressed.  That can require a strong product owner or project manager.  Nevertheless, it is possible and can provide working software for customers in a much shorter timeline.

The Cancer pattern has a word we do not have a favorable view of.  However, this pattern is becoming needed in more and more environments.  This pattern is one for conversions and migrations.  We do not always have a clean slate for our architecture.  Thus, we need designs to handle the modification of an existing architecture. The Cancer Pattern Defined The way Cancer evolves is that it replaces cells with something new while leaving things functional.  This approach is how we often want to replace a system in place.  We cannot shut things down and might not be able to do a swap.  The cancer pattern is a sort of "hot swap" of a system with a new solution.  We do not address the entire thing at once.  Instead, we selectively update, upgrade, or replace pieces at a time.  As time goes on, we can entirely replace the system.  Sometimes without end-users being any the wiser. Applying The Pattern The key to this pattern is to isolate the pieces of the original architecture.  We want to avoid making more changes than needed.  Likewise, we do not want to de-stabilize the current system.  Think of a Jenga game where instead of removing blocks from the stack, you are replacing them.  When we replace a piece of the system, we want to make sure we do it in a way that mirrors existing integrations wherever possible.  You can review the microkernel pattern for another way that components are viewed as a plug-and-play approach to functionality. Challenges Stability is the issue with this pattern.  When too much change is tackled in a batch, it can bring down the whole system.  There will also be integration details that can keep a component from being cleanly replaced.  Those situations can require some thinking layers or kludges to hold things together until we can craft a better replacement.  This pattern is also a time-consuming and complex one to implement.  You are not working from scratch.  Therefore, the original system needs to be understood in detail.  Then those details are used to map to the new solution.

We return to pick up a couple of new patterns.  In this episode, we look at the keep it simple pattern and how to apply it to architecture.  It is a pattern that we often overlook.  However, it is an essential piece of many successful solutions.  It is the heart of our desire to break complex things down into small pieces we can tackle. The Keep It Simple Pattern Defined We run into this pattern, or mentions of it, in many areas of life.  Software architecture is no exception.  When we face a decision to build a complex solution or a simpler one, we want to choose simplicity.  Yes, complex solutions can be fun to tackle and impressive.  However, they have more room for mistakes and a lower chance of success. That combination of low percentage success and high percentage for mistakes combines into a challenging anti-pattern.  Therefore, we use the keep it simple pattern to avoid that trap.  This approach is defined by a desire to keep every decision as direct and straightforward as possible.  While the solution may not be simple, it is an attempt at the lowest common denominator approach to solving a problem. Applying The Pattern We have seen numerous ways to implement this pattern in our look at patterns and anti-patterns.  First, we break down our solution into smaller problems.  Then, we build solutions a bit at a time and put them together for the overall solution.  The pattern is to avoid adding complexity unless we are forced into it.  Clever solutions can impress others.  However, they also are not helpful as a foundational piece for a larger solution.  We want to build solid, stable, and reliable bricks to craft our solution's strong foundation. Challenges There is a sort of boredom or lack of excitement from simple solutions.  They do not challenge us as much as big hairy audacious obstacles.  We must remember that the goal in building a solution is not to make it fun or challenging for the implementors.  The goal is to provide a solution that satisfies the customer.  When we focus on the problem and a direct solution, we are more likely to apply this pattern.

We looked at an incorrect focus based on faulty data analysis in our prior episode.  This time we explore solving the wrong problem with the misdirection anti-pattern.  While this situation can arise from the data bigotry anti-pattern, it is often a failure to grasp requirements fully.  It is a problem that comes from improper focus and lack of communication.  Those are two prevalent weaknesses in a project that lead to challenges and even failure. The Misdirection Anti-Pattern Defined This anti-pattern is simply defined.  We are not solving the correct problem.  Yes, there is a  problem described, and it might even be correctly addressed.  However, it is a red herring of sorts and not what we need to solve to make the customer happy.  Similarly, it may solve the problem but in a completely irrelevant way.  That second situation can make this tough to assess.  Likewise, it can render an entire architecture obsolete or insufficient. The Anti-Pattern In Action The misdirection anti-pattern often arises when the focus is on the answer rather than solving a problem.  Thus, we can even pass through QA and testing with flying colors.  We get the correct answer while reaching it incorrectly.  When we "show our work" for the solution, we get a zero for that portion.  Similarly, the incorrect solution will often fail to address outliers adequately and may fail to solve it for all happy paths. My favorite example is a request from years ago.  We spent weeks working on building a report that could display hundreds of thousands of rows in a reasonable amount of time.  The query result set was huge, and even paging was slow.  They needed the whole report but only cared about the last page.  That is where the misdirection anti-pattern became apparent.  The actual goal was to get a count of records.  The details of each record were not helpful in this situation.  Thus, the query only needed a summary and not all of that detail.  Unfortunately, this is not at all uncommon.  There are many examples of reports and results with a lot of detail that is often ignored.  The wrong problem was solved.  Therefore, the summary data provides the answer, while the details are extra work that is not needed.   Avoiding The Anti-Pattern There is a useful method architects use to gather requirements.  They follow each answer to a requirement by, "and then what?"  That approach helps us avoid this anti-pattern.  It requires a solid understanding of the problem and also its context.  We can not ask about pain points and then jump right to relieve those.  Instead, have a conversation around the issues and obstacles that highlights the various options available.  This process includes suggesting a couple of solution approaches to determine whether the pain point is the source of the problem.  It is like a doctor that asks a patient what hurts, and instead of addressing the hurt, they dig to find its source.