Alternative Open Source: the Good, the Bad and the Ugly

In English, we say too many cooks spoil the broth. And this maxim holds true in development, as well. If everyone leads in their own direction, no one is actually leading.

Here’s a good example:

I was working as a developer on a three-person team. Each of us was responsible for his own project, but we all wrote in JS. We were each encouraged to choose whatever open source we saw fit, to make our work as fast, efficient, and accurate as possible. Makes sense, right?

I chose Commander as my command line parser. All was running smoothly, until I was asked to help one of my co-workers with his project. This is when things got complex. My co-worker had chosen a different command line parser, Yargs. This meant that I had to learn a whole new open source syntax in order to give my input on his project. Annoying and time-consuming, but not a huge impact on the project overall.

But then it happened again.

My other co-worker needed help, and he’d chosen Minimist for his parser. So, to collaborate with two developers, I had to learn three different open source syntaxes. This was more than just annoying, it was hurting the project’s KPIs.

Here’s the Thing: How Many CMD Parsers Does One Team Need?

There’s a moral to this story. Today’s development ecosystem is hyper-agile, and velocity expectations are through the roof. We’re using multiple programming languages, with different stacks, and different tools.

We’re piecing together hundreds of application building blocks from open source and proprietary packages, third party APIs and technologies. We’re running forward so fast and we’re not looking around us.

And if it’s happening in a small way with small teams like mine, you can bet that it’s happening in a big way with larger teams.

We need to understand that with so many balls in the air, there’s no way a human can keep track of them all. The financial and reputational price tags of development mess-ups are simply too high.

This is where intelligent and advanced tools like datree come into play. With 1-tap, datree maps and catalogs all past and present code components, people and repositories to help the developer within the organization to share knowledge, collaborate and reach a state of full visibility.

This way, each developer is able to have a ‘sneak peek’ to his team mates stack, so he will be able to select the right code component for the right job based on data — avoiding developer horror stories like this one.

Originally published at www.datree.io.