At DMD, problem-solving is at our core. Our suite of data products solves the marketing challenges our healthcare clients routinely encounter.
Like any progressive technology company, we run into our software engineering challenges which require creative solutions. Using resources like open source libraries allows us to leverage the collective knowledge and experience of both engineers and programmers who serve the broader community. It’s a valuable go-to; but unfortunately, those libraries occasionally have issues of their own.
In one recent case, the ingenuity, expertise, and proactive thinking of one of DMD’s own created a solution for all. I sat down with full stack developer, Zack Holyszko, to learn more about his image processing fix that not only solved our internal issue—but served as a solution for the library and its community of users.
Sarah Brown: How did you happen to come upon the issue within the open source library?
Zachary Holyszko: The library, called PNGJS, has been around for multiple years now and is the de-facto library to handle the Audience Identity Manager (AIM) use case we were working on. The infrastructure that it's written on is called "Node.js" (https://nodejs.org/en/), and they issue a release about every six months. With that, they had a breaking change—they changed the interface on how certain parts of that environment work. We started seeing the warning they put out, in response to the change, within our application and realized it was because of this library they hadn't updated.
Sarah: What inspired you to pursue getting your solution accepted by the library?
Zachary: What I did, originally, was to make a version internally that fixed the problem, because we can't wait for other people to jump in, right? We had our own fix, so we used that for the last eight months or so. But in the meantime, I was thinking, “You know, I fixed this problem. But it's good to give back to the communities that provide us these tools. Hopefully this can help other people.” I really do appreciate all of the hard work and diligence that these teams put together.
Sarah: From my understanding, PNGJS may have a limited team dedicated to quality assurance, which makes your contribution even more valuable. And I know you’ve worked for companies where QA is of utmost importance. Can you share a little about how you have brought that attitude to DMD?
Zachary: I worked at a pharmaceutical company, where FDA quality assurance teams were heavily involved. That partnership, between developers and QA, for example, is so important. The way I always heard it described is that testing and quality are like the brakes in a car. They do nothing but slow you down.
It's good to give back to the communities that provide us these tools.
But, how fast would you drive your car if you didn't have brakes? You're not going to go very fast. As engineers, we're the engines, we want to go fast; we want to do whatever we can. Having that testing, having that quality team to be able to say, “Hey, hold on a second, you broke this.” Or, “This isn't working just right. Did you check this?” That lets us stay focused on innovating and producing new features while not having to make sure every single second we didn’t hit a pothole.
Sarah: When you look at the fix you put in place, do you envision having to repeat something similar in a different scenario? Would you do it again?
Zachary: I would definitely do it again, especially because one of the benefits is that it avoids additional work we have to do internally. Once we create our own fix, our internal fix, we effectively lose all new fixes that are done in the main catalog of fixes implemented by an open-source “library.” That means additional work for us to try to keep our internal version up to date. If we can get our change fix merged into the main catalog, we get to use the main catalog plus all the new capabilities they keep on adding. We get all the benefits of everything. And that’s no additional work on our part.
Sarah: This is an impressive achievement, to say the least. How do you see it impacting the way you and your team members at DMD operate going forward?
Zachary : I think the biggest takeaway is that these external libraries are no longer “black boxes” we can't touch. Do we just have to assume they do what they say? Previously, if they didn’t perform, then that's our limitation. Now, it’s expected that we’ll investigate why.
Sarah: Ah, so now it's known that we are committed to bringing these solutions back to the community, not just to DMD products and clients. Zack, I know you’re not the type to “toot your own horn,” but this was truly integral to the innovation and technological prowess that characterizes DMD.
Zachary: Thank you, Sarah. Part of me looks at this and thinks, “Okay, it's 22 lines of code, and it's a bug fix that didn't exist two years ago because the environment didn't have that bug or it didn't consider that a bug." But, the other part of me, as a software engineer, appreciates that it's the first step, among many, in terms of leaving our mark on something that impacts the coding community—and maybe beyond.
