Ok, they may not dream of reinventing the wheel, but they sure write a lot of code that looks like an attempt at reinvention.

I’ve been guilty of this too. There is pleasure in knowing that you’ve done something as great as inventing the wheel. And a reinvention promises to be greater yet.

Still, the truth is, whenever we try to reinvent the wheel, quite often, our new rotating incarnation ends up being worse in quality than the one we could have bought off the shelf (or pulled from an existing open-source library).

At Tonic, we once tried to build our own integration engine. It looked simple enough. And it worked. The only problem was what we built lacked a UI. And our goal was to separate integration work from engineering work (can’t do that without a UI). To achieve that would have needed to rebuild the equivalent of MuleSoft or Coreppoint. After a year, I made the team do a formal evaluation of external options and we picked an integration engine and sunset our internal product.

Don’t get me wrong, there are times when building something that reinvents the wheel is the better option. In the example above, if our integrations were simple and routine, using a swiss army knife of an integration engine would have been overkill. When you can build something simpler and nothing simple is available off the shelf that is usually the better option.

But all too often, when we need a boxing helmet, wrapping our heads in bubble wrap (although a creative solution) will always end up costing us more.

Follow me on LinkedIn for more insights about life, entrepreneurship, and building great offshore development teams.
#team #work #engineering #building #engineer