Issues arise each day in the process of working on any project through completion. We have all been there. But at the same time, certain kinds of issues need to be addressed in specific ways. Many options may exist, but it is very rare for all the possible choices to be equally appropriate. Building a solution is generally not a free-for-all across subteams.
Suboptimal Approaches
As an example, consider the option of a single data structure with two percentage columns. If for some reason the integration processing happens to populate one of those columns as a formatted percent, meaning the value 100 is 100%, and the second column populates so that a value of 1 is 100%, then there exists an inconsistency that needs to be addressed. There are many ways this inconsistency may be managed. The DBA team could create a view on top of the database structure reformatting one of the columns to align with the other. Similarly, the dashboard solution could handle the reformatting of one column as just a view, but inside the dashboard tool’s semantic layer. While either of those options could address the issue by covering over the inconsistency, each would still leave the actual problem unresolved. What is needed is a change to the integration processing so that both columns are populated in a similar fashion, according to whichever approach is the standard for the IT shop involved. It is only by making this adjustment that the resultant data structure is safe for every user, regardless of the tools they choose. Selecting any other approach to address the inconsistency is, at best, suboptimal.
A Lack of Communication and Management
But that does not stop many shops from opting for one of the suboptimal approaches. The reasons for using a less-than-satisfactory path may be many. They may include a misguided concern for speed-to-completion or be a matter of the areas of control for those “in the loop” on the existence of the issue. Largely, this involves communication or, more precisely, the lack of communication.
Perhaps, if an actual log of technical debt exists, and such issues make their way onto such logs so that they can, and will, be fixed properly later, then the temporary patch can be tolerated. Sadly, such bigger picture-tracking is rarely in place on most projects.
Choosing the less desirable path generally results from ineffective management. Either management does not bother to explore how an issue should be addressed, or management may have asked the entire project team to simply “jump” at every issue, thereby compelling individuals to fix every problem, regardless of whether their assigned area is the appropriate locale for a fix, so that they may be the heroes for a moment and “prove” their worth to management.
The Ultimate Problem With Workarounds
In the short run, such workarounds are moot. The ultimate problem with them is that, similar to temporary taxes, efforts never emerge to go back and update things with the proper fix. In the earlier example, an organization may simply leave things so that forever more that single data structure has two percentage columns expressing the percent values in two differing formats. This means that all users going forward who are using some form of access to the data other than the original solution must understand and create their own workarounds despite the fact that a simple and relatively small fix back when the problem was first noticed could have resolved the issue.
Please find a way to side-step such management pressures. Stop and smell the roses a little. Take just enough time in the process to communicate issues of concern to the right people at the right time, before committing to a half-thought-through workaround that may very easily end up inappropriately institutionalized.