Develpreneur: Become a Better Developer and Entrepreneur

This episode covers one of the more dramatic points of my youth where a lack of caution lead to me being declared dead.  However, the declaration was hardly from a medical professional.  Nevertheless, the impact to others was a lesson in itself to consider the source for any messages.  I digress, this focus is on the initial mistake and rushing forward without proper analysis. Lack Of Caution Can Lead You Over A Cliff We often talk about momentum and how that can work in our favor.  However, it can also work against us.  Boxers and similar fighters will tell you how you must maintain balance and not over extend.  History is also full of examples of momentum gone too far.  The day I got stuck and fell out of a tree is a nice and concise example of realizing too late that you crossed a line you did not want to.  There are countless areas in life where this applies. Proper Level Of Analysis There is another side to this where we spend too much time analyzing and then we lose windows of opportunity.  Thus, we have to find that "happy medium" where we are able to see far enough ahead to avoid potholes.  There is also a level of risk we need to be aware of.  We will have times of clear sailing that allow us to run ahead at full steam.  Likewise, there are dark and cloudy times where we need to slow down and proceed with caution.  A lack of caution in those latter situations can cause needless pain and suffering.  The trick is to be aware of your environment and whether it is safe or requires caution. If you like this season, you will probably like Scott Adams' book, "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life."

We explore another auto-related mistake in my past in this episode to spend time discussing a need to highlight features.  In fact, an argument can be made that unknown features are not features at all.  For example, I can give you ten dollars, but if I do so by hiding where it cannot be found that is not helpful.  Am I even giving you anything in that case? Highlight Features, Users Want To Know The feature in our story of a handicapped parking space is one we expect all parking lots to have.  However, it is only useful when people know where those spots are.  While the story has a special situation that hides the feature, I have seen plenty of similar situations where these spots are poorly marked at best.  Thus, it becomes too easy for that feature to be lost to those that can use it.  This same situation occurs at times with VIP or other parking spots/areas that are not marked well.  People that might want or need to use the feature miss out because they do not know how to access it.  When we create a feature for our customers, we need to make sure they are notified of its existence. Make The Work Matter Every feature big and small requires effort.  There is planning, design, implementation, and testing that goes into every feature.  It makes no sense to use those resources on a feature only to see it never get used.  We need to consider communication through navigation, notifications, and other methods.  Thus, our users can easily determine where and how to use the features we provide.  When we fail to highlight features we might as well have never created them. If you like this season, you will probably like Scott Adams' book, "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life."

This episode is a tale that shows us that we should question everything.  Yes, even our assumptions.  Actually, our assumptions first.  We have so many sources of information available and yet we still tend to rely on only a few.  Whether that is our point-of-view or intelligence gained from "reliable sources", we give them too much credit.  Everyone makes mistakes and resting too much on an error can be a recipe for disaster. Question Everything - Even Your Givens When we talked about anti-patterns, we saw that a lack of facts could lead us down the wrong path.  This situation often came from a lack of reliable communication.  We could also see it when the requirements were not properly or fully defined.  This obstacle does not stick to software design.  It can appear in nearly every decision and problem-solving situation.  That is at the core of the idea of the fog of war and how it impacts decisions.  We have that "fog" throughout our lives and often do not realize it. New Paths And Avoid Embarrassment When we put aside assumptions we open up new paths for a solution.  The story I share is a good example of assumptions blocking us from a good solution.  When we shut our options down, we may end up forcing a complicated or wrong solution.  Instead, we need to know when we are ready to question everything and find alternate paths to our destination.   If you like this season, you will probably like Scott Adams' book, "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life."

The first mistake I want to share in this season is when I chose a major in college. While I was young and naive, it still is a teachable moment to prepare for meetings. This incident was not my last mistake around meetings. However, it is a good launching point for those further discussions. The error covered here is also one that may set the stage for later mistakes.  We will discuss those as the season progresses. Prepare For Meetings Large and Small No meeting is too small. That mantra can help you avoid all sorts of mistakes in life. I have found that we often discount a meeting or discussion, fail to prepare, and then wish we could get a do-over. This situation is not just one that occurs in business. How often has your personal life included a flippant or off-the-cuff remark that set the wrong tone? When we over-prepare, we will not regret it as much as when we under prepare. But, of course, that also means we should be confident enough to cancel or reschedule when we realize we are not adequately prepared. Decisions Matter While we focus on our need to prepare for meetings, there is also the idea of decisions making a difference. We may be asked our opinion or select a path without realizing it. Maybe this episode will help keep us all more alert as to when we are being asked to make a choice. The roads we do not travel are almost as important as the ones that we do.   If you like this season, you will probably like Scott Adams' book, "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life."

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.