Today, I want to address the issue of reinventing the wheel in the name of comfort. Before you feel like I'm singling you out, consider that I have rewritten or helped to rewrite things because they simply weren't using my common tech stack. I'm going to put this in the context of asset compilation as it seems to be the leading edge of the sword in this drama of reinventing the wheel. It may feel a bit disjointed, but I want to strictly address a few key points:

I Don't Want To Have To Manage Another Tech Stack

This is probably the most reasonable of the excuses I hear out in the wild. Honestly, dev-ops can be tricky: on one of my servers I skipped a step somewhere and it took me 3 hours to get RVM working properly. But, really consider (worst case scenario) it takes you a few hours to setup RVM, or Node, or whatever and maybe some time here and there debugging, it will take you a lot less time than rewriting an entire library! In reality, many systems are able to leverage a system level software manager (yum, apt, hombrew, macports), so installing something usually is as simple as adding some repositories, running a few commands, and grabbing a coffee.

If you are in the awkward situation where you have company constraints limiting your tech stack, I have a few things to keep in mind. If your supervisors are limiting "Tech A" (let's say it's NodeJS), is there a chance that they will come back eventually and say you can't use "Tech B" (LESS for this example)? Could you talk them into assessing the gains of adding the required tech stack? Should you be using something else? If you want to use a technology, but your company has a policy that conflicts with a requirement of that tech, then look for alternative tech. If your company is still won't budge, I say cowboy up and ride your decision (I don't take responsibility for any lost jobs or career ramifications of resulting actions).

The Syntax Tree Isn't That Hard To Replicate

This is something that really irks me. Yes, things like SASS and LESS are pretty easy to build a "normal" compiler for. But, what are you sacrificing?

Will your new compiler allow for extensibility? For example, there are a lot of SASS compilers that are pretty darn close to the spec, but you can't use any SASS plugins and they aren't compatible with Compass. On the other hand, with LESS, yeah you can do a lot of the simple features pretty easily, but almost all of the non-Javascript based compilers lose the ability to utilize the ability to run Javascript functions and computations on properties.

Can you make something as configurable as the original? It's an important question, because there is a good chance that down the road, your convention slightly changes, and will that mean another rewrite just to avoid some dev-op work.

Will you keep it up to date? This is probably the biggest thing that gets on my nerves. Languages change over time. What are the chances that the package you build (or are using from someone else), will keep up with the syntax changes. For example, the PHP LESS compiler is behind the latest spec, meaning that if you want to use new features, you are stuck up a creek. What's worse, if you use a library that requires newer features than your hacked together library provides, chances are you will be hunting down bugs trying to figure out why things aren't working!

I'm Am Using XXX As My Tech Stack

This one is a bit different than having to install a different technology and manage the updates. There are a lot of people who think that they are already using one tech stack so it is easier to rewrite something to fit in that stack than use the real thing. For replicating functionality, this can definitely make sense. But, really ask yourself: could you write a service for this.

For example let's say that I'm on a PHP page and I want to compile a SASS file. Instead of shimming PHP to handle something that already rocks in Ruby, just let Ruby handle the job! This can a bit more advanced and use a queue system and have a Ruby worker. Or you can make it really easy on yourself and just run something like exec('sass /path/to/file'). I can tell you that the time to debug a quick service will be a lot shorter than reinventing the wheel and bringing the PHP SASS compiler up to snuff.

I'm A XXX Developer

Now this is the laziest excuse of all. Programming is about solving tasks in code, and that is a universal skillset. True, I may spend most of my day in PHP and be comfortable there, but I've taken some time to learn a bit of Ruby, just enough Python to be dangerous, and I'm getting pretty competitive in the Javascript arena. To be honest, a lot of the readmes out there are so good that you probably don't even need to really learn the language it is built on. Take Grunt for example: you could really not understand a lick of Javascript, learn the basic JSON sytax for configuration and be out the door doing some really cool things in a few minutes! Even if you do have to learn a new language for the tool, your second or third programming language should be crazy fast to pick up and learn the basics for. At the end of the day, you have not only a new item for your CV, but you also probably will bring back some insights into your native language.

Finally, let's be honest, to port over a library you're going to have to be pretty comfortable in the library's native language. Don't expect to be able to port over something like serializer without knowing Ruby (and some of the Rails magic going on behind the scenes). Even if you are using someone else's port of a library, chances are there will come a time where they say "look at the original docs if you want to know how to do ___".

So I really do have to say: use the tools that exist when you can. Stop wasting good time just regurgitating what someone else has done (and probably did better).

One little bump, if you honestly are iterating on something: making it better, changing the feel, making it easier to use, whatever. This can warrant a rewrite, but still ask yourself if your time would be best spent forking the project and moving from there rather than rewriting it in your native language.