The power to change how an app works in real-time is an underestimated feature of the web. Often it’s assumed that all code, even in web development, should only expose its expected functionality and be completely bundled as a finished product. Once it’s published, you can’t touch it, you can only make unexpected changes by publishing a new version. It’s not as restrictive as going through an app store, but it’s a process of cache invalidation and a page refresh. That’s a good middle-ground that safeguards having development best practices and optimizes for performance while accepting that you’re not able to change your app on the fly.

However, the option to code push changes that immediately take effect is also an important part of the web. At the cost of performance and isolation, you can override CSS styles and JS functions if you leave your code open to meaningful alterations. It’s possible to do this explicitly so that we do take a performance hit, but are able to reason through these surprise changes. In this article, I’ll address why you may want to code push for the web, leaving how to do this for another occasion.

The immediacy of the web is both a blessing and a boon. Since its content is so easily changed, the web attracts use cases where we need something to go online before actually knowing what it should be. In fact, putting anything out there is sometimes the only sure way of finding out what we really want. If you’re familiar with waterfall and agile processes of software development, this side of the web takes us to the edge of agile: build it first, ask questions later. The glossy PDFs of waterfall may still be present as a way to establish trust, but many web projects require the agility of doing the thing before knowing the thing. Web projects can also accumulate several stakeholders and intermediaries, each with their own set of unresolved expectations. 

Often, this process can naturally collapse into successive points of decision by having arbitrary deadlines that get delayed. The project needed to be online by X date so that stakeholders realized what it needed and pushed the deadline further out. New versions can be published, stakeholders refresh the page and the waterfall naturally becomes agile. But sometimes the deadlines are real, they can’t be postponed. For example, in the context of news reporting, live streaming, or just events in general, the web app either shows up on time or becomes irrelevant. 

And then, when some change still has to go live, even refreshing the page is up for grabs. It’s possible to force a page to refresh itself if needed, but that’s not the best UX and you’re basically coordinating a spike in traffic that reloads everything when you probably just needed to hide a single button or tweak its behavior. Letting your app keep its state but introducing some extra code or overriding a specific method, degrades performance but allows you to control this update process without a page refresh. This trade-off can be planned for, but it can also just be a possibility that you leave open to account for some important stakeholder coming in with last-minute changes. In a way, the code and how it performs usually reflect the human context that creates it.

Code pushing (also referred to as monkey patching) can also allow you to easily separate between changes that are part of how you expect your app to work from ephemeral adjustments that had a one-time implementation. It's not so much like A-B testing, it's more like how exceptions confirm the rule. You already know that your app in production is the result of a solid application plus whatever tweaks may be dropped on it at short notice. When those parachute in, they don't really catch you by surprise nor can they mess with how the app usually works. In fact, you can just code-push them and assess if there's something about them that should really be incorporated. 

This level of openness can also present opportunities to improve your relationship with clients right when they don't expect anything can be done. Although this can backfire if taken to an extreme where every decision comes after the last minute, if something truly unexpected may threaten how much value the app can deliver, code pushing that problem away can score a lot with a client. Especially if they're used to a more traditional "it is what it is" tech offering. 

Speaking of clients, if somebody else is paying for the app, this approach also aligns itself with the healthier value-based pricing that most benefits both sides. With hourly-based pricing, you're motivated to take as much time as possible and avoid situations where you might have stepped in with a well-calculated 5-minute code push that saves the day. The code push is there to guarantee that value is delivered and if it can be deployed in just a few minutes, that's another plus, not a conflict of interests. 

Of course, there are always limits to how far you can code push your app, given the complexity of interconnected features and the trade-offs with performance and best practices. Some assumptions can be so fundamental to how an app is put together that they can't be modified on the fly. But code pushing is inherent to the web, an option that you can always position according to your needs and circumstances. If the possibility might interest you, look out for another article getting into how it has worked for me. Thank you for reading.