When Is It Okay to Reinvent the Wheel?
It took fifteen years for “Hallelujah” to become a hit song. Today it is covered by, apparently, everyone. The original version came from Leonard Cohen. He rewrote it many times before finally being told it wasn’t ready. He kept playing it at shows and eventually put it on an album. No one cared. Then it was picked up by John Cale. He covers the song on a Leonard Cohen tribute album. No one buys that either, except Jeff Buckley’s friend. Buckley listened to the song, made his own version, and put that in his album “Grace”. The album wasn’t a commercial success. Buckley tragically dies. The public revisits his work, and so, finally, “Hallelujah” becomes a hit. The song went on to be covered by, well, everyone.
That’s the abridged version of the story Malcolm Gladwell tells in his podcast “Revisionist History.” From the versioning Leonard Cohen does with his original version of “Hallelujah,” to workshopping the song during shows, to the first release of the song, to covers and covers of covers, we see the benefits of iteration, reuse, remixing, and creation. All of these have a place in development, but there seems to be an emphasis on reuse. Remixing and creation reach almost taboo levels in agency culture. So, imagine this: John Cale never covers “Hallelujah,” instead he invites Leonard Cohen to open for him with his version of “Hallelujah” at a show. No one cares. Years later Malcolm Gladwell is missing one of the pillars for his episode of “Revisionist History.” I can’t come up with an introduction to this blog post. You never read this. Agency culture remains unchanged forever. I, for one, am glad I don’t live in that universe.
Little Boxes Full of Code
When it comes to dev work, remixing and creation are sometimes thought of as “reinventing the wheel.” Building your own stuff is generally viewed as some sort of bad practice. Developers tend to approach problems by first seeing what is already out there. They use prepackaged bits of code that can be plugged into their code. A developer may work on a project where the majority of the codebase was not hand-written. Maintainers (communities or individuals scattered across the world) tweak, secure, test, and perfect the bulk of the code on most websites. Maintainers share and iterate on the code. Developers use the code. Often times, they file bugs and suggestions, and then maintainers iterate on the code some more. Everyone is happy.
Existing code comes with downsides though. In theory anyone could become a contributor to a project. That doesn’t guarantee a single contributor may have much of say in the direction or priorities a project cares about. You may want to narrow the scope of functionality, while the majority of people want to expand it. You may want support for old browser, while most everyone else wants to drop support for those browsers. Code bloat is a common problem is open source code because so many people want so many different things. Plus, requirements and existing code don’t always align. The difficulty in development is a mixture of finding the right existing code, knowing how to extend it, and knowing when we need to build something new.
Don’t Reuse. Build Something New.
Utilizing existing code is important. It saves time – a lot of it. However, after the initial investment of time, having custom tools made in-house will actually save quite a bit more of it. Custom tools can be built right into your process, can integrate with anything, can be as modular as you want it to be; when tools are custom, they can grow and change specifically to fit your needs.
Aside from being a timesaver, creating custom tools might go far beyond a solution for one particular project. Many popular frameworks, libraries, and tools being used today were at one point made to solve one specific problem at one specific organization. The Bootstrap front end framework for example, was built at Twitter, where it was known as Twitter Blueprint. It was used as an internal style guide for a full year before being released and becoming what it is today. A similar story explains Zurb’s Foundation front end framework. Angular and React are javascript frameworks used by Google and Facebook respectively. Drupal was built by Dries Buytaert to talk to his friends, and was basically a message board. Whenever it makes sense there should be initiatives to build custom tools, frameworks, and products.
Additionally, most developers would agree that build your own stuff is an exciting challenge of progress. Maybe you’ll write some library and endlessly rework it… then no one pays attention to. One day someone picks it up and makes their own version and credits you as the inspiration. But STILL, no one pays attention to that. But then a young developer picks it up and she makes a definitive version of your library. Then someone hates it and makes something better. Progress.
Not every agency or person can create a remix of all the code they use or invent brand new tools. One of WDG’s Drupal experts says, “I won’t personally write a CMS, I’ll use Drupal or WordPress. Here at WDG we probably won’t develop our own browser the way Google did with Chrome. We do however develop our own plugins and modules.” Jarvis, for example, was developed as a WordPress plugin to address an internal need. While Drupal hasn’t accepted the Jarvis module yet, it is used in house. Other internal projects being worked on include a wiki that integrates with third party tools commonly used, such as WordPress and Drupal profiles, a Gulp starter kit, and complete web development toolkits.
If you’d like to listen to the “Revisionist History” episode that inspired this post it is titled “Hallelujah.” Also mentioned is bootstrap, foundation, react, and angular.
Contact us and let us know what you think on twitter @wdgtweet.
