Here’s a typical scenario that you might recognize. Your boss sends you an email about an issue in the production environment. You research the issue and immediately find that there is a fast way to fix it, but it is kinda/sorta like a hack and you’d eventually have to refactor it in the future if you wanted to extend the functionality of the feature. You study the problem some more, and realize there is an opportunity here to add more functionality for the users of your product while fixing the issue your boss sent you – the problem with this approach is that it will take at least a week longer than your quick fix. You may have already intuited that there is a third option, which is between the first two I mentioned – industrialize the quick fix but it will take longer to get into production by several days.
Many times in my experiences I’ve found out, ex post facto, that a junior developer will opt for the quick fix band aid. This is one way how fragility and technical debt get injected into the codebase. Similarly, you will find that some seasoned developers will choose the option with the longest implementation time to market because they are driven to create the best possible solution they can – and let everyone know that it has to be done perfectly if it’s worth doing at all.
What developers fail to recognize here is that management has to weigh in the balance multiple competing agendas. A few that come to mind are: customer experience, breakage, and prioritization. The customer experience is something everyone in the company should be interested in. For this particular issue your boss told you about, you should without being asked, try to find out the volume of the issue, and the run-rate. In other words, when did the issue happen, and how many times a day / how many users a day does it affect? Once you quantify the issue, a severity can be gleaned from the results. If the volume is high and impacts revenue then that’s what breakage means. (I tried to find a good definition of breakage but Google kept pushing hair product results at me???) Breakage can be thought of as opportunity cost but that’s not technically correct. You’re not giving the user an alternative you’re removing a an opportunity because the feature is broken. Lastly, if there are high priority features that must wait while you repair existing features that might jeopardize the timeline and release date of the pending launch.
Using empirical metrics calculated by debug logs or sales figures will quickly help you ascertain what the priority of a quick fix is. If the breakage is small or (if you’re lucky) zero, then you can wait until a scheduled release and opt for an industrialized fix or potentially the “Boy Scout fix” which is the second option outlined above. If you respond to your boss quickly with data that supports your recommendation you will have hopefully scored big with her because she will notice you have anticipated business questions and delivered a menu of choices that have accompanying data to lend credence to your conclusions.