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.
