Software that shouldn’t be fixed

posted: April 6, 2023

tl;dr: What to do when too many users are relying upon buggy software...

Software’s greatest power is its ability to be changed. This is why the word “soft” appears in “software”, in contrast to hardware, which is much more difficult to change after its initial release to the field. It’s also why I argue that field upgradability is The first feature to put into any software product.

Software’s ability to be changed can be used to add features, improve performance, and especially to fix bugs, where a “bug” may be a coding mistake, a design flaw, or some other defect that is noticeable to users. Sometimes, however, the software and the particular area containing the bug has become so widely used that it shouldn’t be fixed. This happens when a non-trivial percentage of the software’s users have experienced the bug, noticed it, and adopted practices (a.k.a. “workarounds”) to mitigate or eliminate the impact of the bug. Fixing the bug will likely break many of these workarounds, causing another round of pain for the users who rely upon this aspect of the software.

A classic example of this situation is JavaScript’s Date class, which can be used to instantiate date objects representing different dates. I instantiated a date object for today’s date, which is written 2023-04-06 using ISO-8601 formatting and 4/6/23 using date shorthand notation common in the United States. The date object comes with methods to extract the year, month, and day of the month. The year comes back, as expected, as 2023, and the day of the month also comes back as expected, as 6. But when the month is extracted, it comes back as 3, not 4, because JavaScript chose to start numbering the months at 0; the years and the days of the month start at 1. This is but one of many quirks in JavaScript, and at this point in the language’s history, programmers just have to learn to live with them.

A computer terminal window with a black background and lines of code in mostly white lettering along with some pink and yellow

Is it 2023-04-06 or 2023-03-06?

A more complex example is one I recently encountered with Salesforce Marketing Cloud (SFMC). It turns out that a popular way of sending bulk email blasts, by using a data extension loaded with the intended recipients and their email addresses, does not actually use those email addresses if the intended recipient has been sent to before. In this case, which is typical, SFMC defaults to the email addresses previously used for those recipients, not the newer, better email addresses in the data extension. Other methods of sending bulk emails, such as by using the more modern Journey Builder functionality of SFMC, will use the email addresses in the data extension. For a succinct description of the problem, go to the 1:39 point in this YouTube video.

Like JavaScript’s Date flaw, this SFMC behavior is due to the way the code was originally written and released. If SFMC were to rewrite this functionality from scratch, they would not choose this particular behavior. The fact that Journey Builder does not do this indicates that SFMC considers it to be undesirable behavior. Yet it is too late to change it. If SFMC were to change it, their customers who have gotten used to the flaw, or who are unaware of it, may be surprised to see that SFMC’s behavior has changed and it is using different email addresses than in the past.

The original, buggy piece of software should not be fixed, because too many users rely upon its abnormal behavior. The best path forward is to leave the buggy software in place and reimplement it anew as a new feature or functionality that the user can potentially choose to use in the future. This puts the user in control of whether or not to incur the cost of switching. The user also gets to determine the timing for doing so. This is effectively the path that SFMC chose for the flaw described above, as Journey Builder fixes it, and users can migrate to Journey Builder whenever they want. JavaScript also often reimplements features under new names, correcting the sins of the past.

The downside is that the code base grows and maintenance costs increase as a larger codebase needs to be understood, developed, and tested for each release. To reduce these costs it may be possible to deprecate and someday eliminate the older, buggy software after users have been given plenty of time to migrate. Sometimes, however, that time never comes.