How We Started Sharing Code Between Projects as a Team
Jonathan Saring

My experience with sharing components in the company has not been a good one. I don’t think its so much the method of sharing that is the problem which this article tackles and promoting their app as well, but just the concept will not work depending on the company.

I worked at a fortune 500 company where someone had a novel idea. They saw that most of our apps contain the same kind of components like tree navigation, data grids, etc. and thought why not have a special team to create a library so the entire company can use? Stuff like this looks great on Power Point and I have no doubt this person got a big bonus for this idea but the execution is another thing and after a year or two, this project was entirely abandoned.

There were several things that went very wrong. For starters, you need a team with exceptional developers. The ppl that contribute to open source are rarely the casual 9–5 programmers. They are true software developers that love their craft and excel at what they do. Creating truly reusable components not only requires fast performance and maintainable code but bullet-proof testing because you need to cover every scenario imaginable or else it’s not truly reusable. The team that was doing this couldn’t even give us performance and so when other teams started using this library, they were immediately turned off from it because it was very, very slow. The performance improved eventually but not by a whole lot. But by then, trust was lost from within the company. Nobody trusted this library. They instead chose to develop themselves within the team with better and sharper developers. The first rule in creating a truly reusable library: first impressions matter. If it sucks on day 1, you lost everybody’s trust and to regain it is near impossible.

Another problem was distribution. The only way of getting a hold of this library at the time was via npm but npm was not that popular during this time and save for some Node developers, not the method of choice for JavaScript developers. The old script tag was still the norm at the time and so many developers had problems just downloading this library. 2nd rule of reusable components: it has to be accessible via multiple ways and not just the way you think it’s correct.

Lastly, the API docs for this library was awful. It was just some screenshots and a few lines of text. Examples were badly needed as well as making the font size bigger and improving other visual elements of the page to promote readability and make the developer want to spend time there since they will be spending a lot of time there to learn how to use these components. When API docs are always outdated and not clear, you can bet this will be the final nail in the coffin of any reusable library.