Last week, a security-related flaw in Electron, a popular software framework, hit the news.
This was particularly painful as Electron, an application development framework that allows you to build cross-platform desktop GUI applications with web technologies, grew very popular very quickly. Many popular desktop apps were affected.
Before I go any further, in 2015, my team at Wickr opted to go with QT, a similarly-useful application development framework, for our desktop app. QT differs from Electron by skipping the browser on the client-side and integrating more directly with native system APIs to render the UI.
About a year ago, we sustained a veritable revolt from a handful of developers who fiercely advocated that we switch to Electron. It got heated. One side argued that Electron was easier to use (after all, everyone knows Javascript:), was growing in popularity, and “looked better.” The ‘conservative’ view was that it’s less performant, harder to integrate with native code, not proven from a security perspective, and really looks the same assuming the same GUI design. Ultimately, we decided to stick with QT. It was interesting, however, to see how the battle lines were drawn and how developers were drawn to different arguments.
In technology, we are constantly looking for new and better ways to do things. It’s just what we do.
Our offices are dominated by software developers, and if you’ve never had the pleasure to work in such a place, you’re certainly missing out, but I do admit I am biased. Standard attire is a t-shirt and jeans. Business attire? Add a hoody. There’s a time each afternoon when drones cloud the office stratosphere, showing off whatever new lights and accessories were added the night before. At least once a day, a discussion ignites around what we can automate (the answer is everything:), and at least once a week a spirited debate breaks out to settle questions like what’s better, Rust or Erlang? I know I’ve lost some readers here.
For tech managers, the trick is channeling our teams’ insatiable appetite for newness to what is good for the company. Someone has to think through the excitement and dig for the answers that will tell us, figuratively speaking, whether we’re infatuated or in love. Rust is a good example: a couple years ago a few junior developers came to me telling me how cool Rust was and how it would be perfect to use for a new micro service we were building. While they were lauding the syntax, performance, burgeoning community support and adoption rates, all I could think about is just how new is this? Does it have all the capabilities we need, or are they being added every day? How many of our current developers really know it? How fast could we fill a dev position with Rust as a prerequisite? For my team, it just seemed like a risky choice at the time, regardless of how awesome it was.
This isn’t about Electron. For many things, it’s probably awesome and makes total sense to use. To me, it is about making the right decisions for a company for the right reasons. Tech management is a constant tightrope walk between what’s new and what’s better. There’s a strong pull in the industry to do what’s cool and sometimes it’s absolutely the right play. Knowing when it’s time to take either path is the key. For my team, a decision to move to Electron would have been about being hoody cool rather than being better, and from my perspective today, I’m glad we didn’t make it.