Reinvent the wheel and roll your own framework
Rookie software developers — and even experienced developers working in a new problem space — can fall into one of two conflicting traps:
- They use a popular open-source framework or software library, despite the fact that it doesn’t really match their needs (and sometimes without fully understanding it, see cargo cult programming)
- They masochistically or egotistically choose to “roll-their-own” framework or library, building a custom solution from scratch (often reinventing the wheel; resulting in brittle, untested solutions for problems that have been addressed long ago by others)
I’ve done both, of course. Especially in my twenties, I was very big on “rolling my own” everything. It’s not an uncommon mistake among ambitious young programmers. You’ve got youthful arrogance combined with another popular novice activity: rejecting other people’s code as difficult or dumb.
But as the open-source movement (and its promise of handy, pre-chewed solutions) has prevailed, we’ve come to see the opposite happening with regularity. We’ve seen projects that are clunky and heavy, that move slowly, drop frames or feel unresponsive, or that flatly end up unable to satisfy all project goals — because someone chose the most popular, publicly available solution over one tailored to the project needs.
And we continue to see that classic corollary where developers who’ve come to specialize in a particular popular framework or language keep using it… even when it’s not the best tool for the job (the Law of the Hammer).
To be clear, it’s not the software’s fault. The open source landscape is rich, multitudinous, and constantly advancing. Many of the frameworks are being released and maintained by skilled teams working at the biggest software companies (Google, Facebook, et cetera)… in a way, when you choose their open-sourced work, their great engineers — and others around the world — are working for you. And the Darwinian competition that ensues as those frameworks and libraries are used and evaluated every day by thousands of developers only makes those codebases stronger. It’s great stuff.
With thousands of solutions already out there… why would anyone but a fool “roll-their-own” framework?
The best reason to DIY
Despite the apparent consensus that only fools and self-important novices “roll-their-own” when it comes to frameworks, you’ll often see some exceptions tacked on… “Unless you have a niche need or requirement” being one of the most popular.
At Planimal Interactive, we’re a bit niche to begin with. The needs of interactive software for live events and public installations are already different than those of websites, mobile apps, and the other common consumers of open source software.
On top of that, we had our own wants and requirements for our interactives:
- we wanted completely externalized assets so that, in a pinch, content like images and text could be swapped on the show floor without requiring a re-build (yep, even with plenty of advance review, occasionally clients will ask for content changes at the event)
- we wanted C++ native code for performance (modern JavaScript engines have impressive performance, but for many of our installations, where responsiveness to custom hardware inputs is critical, and screen redraws without frame drops or tearing are imperative, C++ gave us a better user experience)
- we really, really, really wanted to follow a pure Entity Component System (ECS) architecture (to provide stability by decoupling data from functionality, and flexibility/reusability by enforcing composition over inheritance)
So we invested the time and built REX™, a pure entity component system-based application framework that completely hydrates itself from external assets like JSON, image, and movie files, and that leverages the Cinder C++ code library for performance across both PC and Mac, and even mobile devices.
REX is now halfway through its third year in production (its first public debut was May 2015 in Switzerland, the next show will be this September in Portugal).
We don’t use REX for everything (in fact, the last two proposals we sent out used React Native and Unreal Engine, respectively) but we do use it for A LOT of projects. You can check out our 2016 reel here or at the top of planimalinteractive.com — REX is driving 90% of the interactives shown.
While it feels a bit crazy (and sort of delightful) to always be coming back to REX, this isn’t a “Law of the Hammer” addiction. It has more to do with the fact that, from the start, we prioritized reusability with REX’s ECS system, and, now that REX has been in production use for over two and a half years, much (if not all) of the code needed to support new REX-based projects already exists.
That brings our costs down. Plus, it means every new client is getting the benefits of a codebase that’s already gone through two years of real-world testing at live events.
Custom frameworks in the wild (we’re not alone)
Despite the prevailing wisdom about not “rolling your own”, it turns out we’re far from the only ones to have successfully built a reusable in-house code framework — a lot of great teams are doing it!
- Active Theory has an in-house JavaScript framework called Hydra that they’ve been developing since 2012 and refer to as the core of their studio. They say that, over the years, Hydra has grown and evolved, and they now use it to power desktop, mobile, Apple TV and even VR and — recently — AR applications.
There are even companies with C++ frameworks that closely parallel REX™ itself:
- Summer of 2014, stimulant built and shared their Cinder-based framework, Cinder-XUI, hydrated from external XML and assets. We looked at using it ourselves around 2014/2015, but it wasn’t built around an Entity Component System, which had become a core requirement for us.
- Potion open-sourced their own scene graph framework for Cinder, po::scene, and announced it in Summer of 2015 (a few months after we’d already built REX). And you can see they’ve been working on a version 2.0 branch as recently as a couple weeks ago.
- Soso Team (Sosolimited) has an C++ openFrameworks add-on called ofxSoso that provides scene graph, animations, and other features. [Side note: in Summer 2015 (again, just a few months after REX), they also shared their didactic Entity Component Systems examples built with Cinder and EntityX , confirming we weren’t alone in pursuing an ECS approach with Cinder!]
You’ll notice that the last few “in-house” examples above are also open-sourced projects on Github. And many of them (including REX) rely on open-source projects like Cinder and openFrameworks.
But then Cinder C++ wasn’t always open-source — it was itself an in-house library originally made by the Barbarian Group. Many popular open-source projects began in-house. The React JavaScript library (which we also use and love) was open-sourced in 2013, after it had already been used in production at Facebook and Instagram for a couple years.
“People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones.” ―Donald Knuth
No rules and no wrong paths
To lightly contradict the quote I just dropped: I do think many of the developers behind the projects mentioned above are geniuses. And if we have the opportunity to leverage their genius through open source software, well, that’s a gift that’s hard to turn down. And we don’t have to turn it down!
You can use those open source codebases or borrow their ideas to create your own — the popular Redux state management system lists several sources of inspiration on their site. My own obsession with Entity Component System architecture began after exposure to the open-source Haxe Flambe game engine.
The pitfalls mentioned at the top of this article haven’t changed in the minutes since you first read them — if you use someone else’s code, you have to be prepared to learn it, and, potentially, to be disappointed with it. You might have to improve it yourself!
On the other hand, if you choose to build your own “from scratch” solution, you have to be prepared to solve problems that others have already solved, to spend two, three, or even twenty times as many hours bug-testing.
But take heart from the companies listed above — there’s no rule that prevents you from rolling your own. Nothing outside of your level of skill/devotion can stop you from building a proprietary framework that powers your business, or from open-sourcing your code and becoming a “genius” that hundreds or thousands of other developers look up to.
Christopher Lepkowski is an interactive software consultant specializing in custom experiences for entertainment and advertising. He is the owner and director of Planimal Interactive in Los Angeles.
