Published on

Mind the stop gap

Authors

Stop gap, quick fix, temp fix.

Call it what you want if you have been developing long enough you have had one or more situations where there was a burning problem which you had to solve ASAP. As a team you agreed the solution used was not ideal at all but you went that route as the issue was critical and you needed a quick solution - now! You also as a team agreed a longer term solution needed to be put in, "some day".

The operative words here are "some day". But we all know that "some day" generally is synonymous with "never" , unless the system is really burning. But even then we or others end up sticking additional layers of duct tape on top of the existing solution until it becomes near impossible to reimplement easily and correctly.

Surprisingly or unsurprisingly even in an R&D setting this is also the case. My colleagues and I were going through an older code base and came across just such a stop gap. It was put in early in the project and like with all projects the gap was plugged and other issues became more pressing. The stop gap worked and eventually everyone forgot about it.

The moral of the story is that when putting in a stop gap assume it will be there forever. Do your best to put in the real solution but failing that put in the best stop gap you possibly can given the time constraints and situation you are in. Also clearly mark/comment that it is a stop gap and try schedule a proper solution in the nearest sprint.