2016-07-03

Open code, a chance for improvement

Since I’m writing code I try to publish as much as I can as open source components. But I had occasion to work in situations where it was not possible. And I noticed some serious differences in the result.

When you publish some code on, say, Github, you can just throw it as is and be done with it. Then you merely use github as a repository provider and don’t care much about anything else. But when you begin to spend some time doing it, you notice that external contributor can bring great fixes, help detect bugs, and generally speaking make your code more valuable in itself.

But this is a two-ways road. To invite people to collaborate you need to address a certain amount of little details. Writing a decently clear README is a demonstration of politeness for any passing guest. It’s just more inviting. Making sure you have a complete enough test suite guarantees you can be sure external contributions won’t mess up existing code (if writing tests in itself was not motivating enough). Refactoring your code by following codeclimate advises will break huge methods in small pieces, making things easier to be improved. Enforcing some kind of style guide will avoid people to get confused by a non-standard code-art. (that person could be you in one year).

All those aspects, when you work at a company as the only coder on one piece of code, you don’t have that much incentive to enforce them. And I know about it because I have seen a huge lot of legacy code that was written that way. With lame tests that only purpose was to enforce code coverage without really testing much, weird code style, epic methods, no instructions. If it’s just you and a couple of friends that you see every day, it’s fine, you can deal with it. For a time.

The fact is that exposing your code brings an incentive to work on the (apparently) non-essential aspects of your code. But those aspects really bring a huge improvement on the long term. Which leads me to consider that opening source code is a way that can lead to make it better.

An usually, I noticed that the bosses don’t care if it’s open or not, as far as there is no trade secrets revealed. But well we write so much code that if business-neutral for many things. At the end of the day, it’s only the matter of asking the boss if you can free this or that code, and then it’s on its way. Even more if the code is published under an organization on github, there is even more incentive to make it clean, and it will also help possible candidates to understand what kind of stack you are dealing with, and what kind of principle you try to enforce. Even if it’s actually only enforced in your open source code and the hidden code is messy. Haha.

So, I ask you now, what in your current codebase could you extract as an open source gem? or node package?

comments powered by Disqus