Code has no legacy.
Legacy code is an inevitable affair. One might argue when exactly a codebase (or a portion of it) becomes legacy code, but it sure isn't hard to spot. It represents where the app is today, and where it came from. This is as far as legacy software is capable of taking you. Beyond that point, the perspective of hindsight, lies madness.
Dignity and dignified are different.
It can be difficult to discard old work. Nostalgia aside, code that works is an achievement, a degree of completion, and perhaps even peace. That is to say nothing of the architectural design, feature set, and relative success of the product assembled by its component parts.
It can be easy to mistake this for a dignified anthropomorphic personification. At the end of the day, despite its flaws, this code is very much the weathered ship captain, teeming with experience and deserving of respect. It works, and you worked hard to get it there. The smart move is to preserve it. After all
if it isn't broken, don't fix it, surely an evergreen truism if there ever was one.
Starting over can present itself as a loss of one's dignity. Deleting working code, whose cost has long since been amortized, laden with the baggage of effort required to bring it to fruition can be deflating. It's an admission that your best wasn't good enough.
The difference between these labels is that one is appropriate and the other isn't. Your codebase, your app, your marketing efforts are not dignified, you are. Code can't gain experience, it can't bask in the glow of success, you can. This makes the baseball bat to one's dignity even more acute. If you are the ship captain (Whose thousand yard stare symbolizes some hidden cognition rather than abject apathy), discarding that legacy code is an admission that your best isn't good enough...anymore.
Glory is supposed to be ephemeral.
Enjoy the sense of satisfaction that launching your app carries. You're meant to, doubly so if deemed a success (by whatever metric qualifies it). This feeling is momentum, don't mistake it for paradigm. Software, like any business, is fluid and requires care. Just because a customer is happy now doesn't mean they always will be. Just because the internet connection your ISP provides is fast enough for now, doesn't mean you won't desire more in the future.
Code works the same way, its purpose and function is not adaptive. The market will move on, with or without you. Software is meant for a very specific purpose, by design static and not malleable in nature. There will never been a silver bullet to fire down the barrel of a compiler. Ignoring market trends even when they do not affect you is dangerous for this reason.
After remarkably short periods of time that once-great work is suddenly inapplicable. This is your last exit from the highway of obsolescence. Once this realization is reached, drastic action is necessary. This is not the moment to update and extend, that window has long since closed.
It pays to maintain a forward looking tenure over one's app. Once stability is reached, the next priority must be progress.
Stability is not the crucible in which success is formed.
This brings us to the motivation of blog post. We recently wrapped up an application for a large corporate client. It required the use of a preexisting (and paid for) VOIP library for its main function. This library wasn't chosen by us, and was purchased long before Teeps was ever in the picture. It was purchased without immediate purpose on the merits of its longevity. The client felt that the stability of this library was tantamount to overall success. This is not surpising considering the industry they're in.
In corporate environments, these traits are desirable. Stability keeps people employed, shareholders happy, and potential issues to a minimum. It's why you see major companies still using Windows 7 and 19 inch VGA monitors.
This blog post was supposed to be about
CallKit, a framework Apple released with iOS10 over the summer that solves a very real problem we experienced building the aforementioned project. The problem involves receiving calls in the background, and how answering is handled. Due to this preexisting VOIP library we were not able to support CallKit.
It's legacy code between 10 and 15 years old. Its creators did not invest in modernization for over a decade. With CallKit's release a particular TCP socket configuration was also deprecated. It was this enum value that allowed this legacy VOIP library to run in the background, keep its socket connection to the server open, and receive calls. This is not only very error prone, but a massively resource intensive approach to transient availability.
CallKit solves this exact issue by allowing a standard push notification to trigger an incoming call. Since a push notification is received en masse by the system, it has no larger resource impact than push notifications in general. Adoption brings with it integration into 1st party call UX as well as automated address book entries.
This library we were required to use cost massively huge amounts of money compared to modern SASS pricing structures and had no native iOS interface. It was a raw C89 interface that hadn't been touched since the early naughties. By this justification it did not deserve the price tag is carried. The opportunity cost of adopting new technologies would have paid off in maintaining a leading position in the VOIP space.
Instead the vendor chose to allow the entire codebase to atrophy and continued to sell and maintain the same product. In the meantime, other vendors have moved with the times and kept their products updated. Adopting CallKit would have been as easy as Apple made it look in the WWDC session. Naturally, we're recommending that our client choose another VOIP vendor for the next stage of development.
There is a degree of comfort in defending legacy code. It isn't hurting anyone, you have other priorities. The danger comes in not equating legacy code with systemic erosion. It's permanence is indicative of rot in the 4th dimension. Recognizing that is the key to longevity, ignoring it no different than believing the sales person who said "You don't have to change the fluid, it's a lifetime fill".