Sharing code across teams: current practices in agency race and how to prevent stumbling

Ctrl+C, Ctrl+V, more than 70% code currently shared on GitHub is duplicated.

Did you just breathe that (no more guilty) sigh of relief and think “So it’s not only us”? Now, granted, most of the code out there is repetitive. Reinventing the wheel (a.k.a. retyping primitive bits of code that display/hide something, etc.) is definitely worse than plastering a dozen lines here and there all over several projects.

Have you ever known people who actually sent JSON files via email?

Okay, we all know there are multiple ways of sharing code and avoiding monkey jobs. The problem is, sometimes these code sharing tactics fail miserably.

Especially when the code is being shared between teams who work remotely.

The next thing that happens after a digital agency has bruised their toes against an unsuitable module system or code sharing practice, they tend to regress to the safe haven of “you do what you do”. In this article, let’s focus on what makes agencies stumble when creating and sharing/adopting code for pharma-related content. By the end, you’ll have identified what stumbling blocks there may be (and if your toes as a manager still hurt, they’ll probably be healing, as well).

Frenetic deliveries, frail ecosystems

With the “normal” rhythm of deliveries and deadlines, it’s hardly possible to blame any agency for poor codesharing practices. This is especially true for the pharma-oriented content: while traditionally the bulk of eDetailers, apps, emails, what-have-you was quite moderate, the situation has changed for many. On the one hand, pharma is noticeably laying more emphasis on digital production. As many as 84% managers reportedly believe that whenever there’s some true customer experience to deliver, content is the answer. On the other, HCPs are not as easy to impress; to appeal to today’s doctors, pharma has to provide not just ‘content’, but highly personalized experiences. In EU, 75% medical specialists explicitly state they want content that’s related to their specialty.

The bulk of content is growing, even when marketers realize that it’s not the quantity but quality that matters – because of personalization. Accordingly, the entire cycle is shrinking, with deliveries coming at a fairly frenetic pace. Under these conditions, there comes the paradox. Setting up an adequate system that allows sharing encapsulated code entities, modules, blocks is becoming more necessary than ever – and yet, there’s simply no time to approach the question scientifically, so to say.

Those who have worked with JS for a while remember the improvised, function-wrapped modules from before NPM and require; but even with ES6, there’s still room for improvement. It’s not just about refactoring and interdependencies, but also things like discoverability and sizing. There are stories about teams who went through painstakingly trying out very different approaches to sharing code, and the more dedicated ones end up inventing their own systems.

Those, however, who don’t have the luxury of looking around and contemplating options, find themselves stumbling over several common problems with different codesharing practices. Here are the painful spots – and the lessons to infer.

#1 Small bits of unspecific functionalities – all too many of them

In one of these stories where they look for ideal not-reinventing-the-wheel solution, a team’s initial practice was publishing their code as modules on NPM. Now guess the problem.

Right. First of all, the split repos by themselves were something to consider. Next, the code was split into small modules meant to be bundled together at some point in the perspective. Normally, of course, this is a good thing – after all, smaller code entities are more readily made self-contained, resembling those ideal “building-blocks” that we strive for. However, in some cases this multiplicity becomes a problem – you can have too much of a good thing, it turns out. The issues of refactoring and ownership of these packages, of course, exacerbated the issue.

As an obvious remedy, there seems to be the idea of a single multi-package repository – but this, again, has its drawbacks: multiple package JSONs, multiple test/build environments – and an uncontrollably complex dependency tree.

The truth is, each team should decide what the optimal package size should be for their specific purposes, and define the ways to store those packages, accordingly. Ready-made solutions are mostly lower-level in terms of both size and abstraction, but to reach ultimate efficiency (and not to regress to “tolerable” practices) an agency deserves to share larger entities on the same self-containing, comfortably encapsulated terms.

#2 How maintainable is it all?

Another issue that many encounter is keeping the shared code accessible and up-to-date. It’s not just the question of ownership, e.g. on NPM mentioned above, but the general discoverability and versioning concerns. While no one would want to install a whole library to use a component, when it’s the other way round – i.e. everything floating free, things become messy. Not only is it harder to find the modules needed, but also the versioning gets complicated quite fast. Now, the higher the change rate/frequency of updates – the more teams are working remotely – and the more testing needs to be done, specifically on the integration level, the more frustrating it gets. One doesn’t have to go far to hear people complaining about linking, submodules only working on one branch, nesting issues, etc.

Again, the optimal approach is to consider how maintainable you want the whole shared code to be – and in what particular ways. For some projects, the focus is on testability; in some, it’s mostly about the plain possibility to find updated versions and ensure backward compatibility. Either way, the system has to be arranged for clarity.

#3 Industry-specific requirements

Who you write code for determines many things, including (crucially) functionality and how it gets constructed from separate elements and modules. If you are an agency working on pharma eDetailing presentations, for example, there most certainly are recurrent elements that customers request most often. Take a carousel with expanding elements that contain, say, patient profiles. Think of all the probable variants to implement this, a bunch of carousels, each of them relying on some shared functionality and building upon it. Now, the “core” functionality will very likely be assembled from more basic modules – and if these tend to be too small, there will appear all the problems with refactoring, testability, and linking. Of course, there’s also the reverse scenario, in which the packages used provide go-along bits you don’t really need, creating unnecessary interdependencies and devouring resources. Again, with pharma there are even more specific functionalities, especially related to the (extraordinarily well-developed) CRM and medical/legal review systems used, like IQVIA or Veeva.

This is why, ultimately, code should be encapsulated, packaged, shared and updated based on industry-specific functionalities. The industry is, of course, whatever the customer intends to do with the deliverables once they leave your agency to see the daylight.

Trial and error is not the only way it is

Have you recognized any of the issues mentioned above? If so, you’re not alone, especially if your agency is specialized in medical content. There seem to be no ideal ready-made solutions around, as if everybody were to design code-sharing practice of their own. But do you really have to go through all that evolution on your own? Of course not.

The reason why widely accepted module/package systems are easy to misuse is that they are for everyone – from website developers to mobile app designers. To adjust them to one’s needs will mean a lot of workarounds and duct tape hacks. Working with frameworks, storages, and platforms that were initially built around the needs of your own “segment” is more comfortable. For pharma content development, you can consider the possibilities of eWizard platform, where the available modular components are designed specifically with pharma content functionalities in mind – and with the purpose of saving time on repeated combining.

Eliminate the anxiety of incorrectly split code packages – and you’ll see how surprisingly fast the different teams can really collaborate once they get to focus on the real tasks.