“It is so cumbersome to have go round talking to people and submitting pull requests. Can’t we just go ahead and just duplicate or do whatever we want?”

Yes, working together and collaborating is hard. It requires a willingness to listen to others and learning about different points of view. This is of course something which takes time to get right.  Because it is about people and dealing with people is different each time and for each interaction.

The past few years there has been a tendency to focus only on a team. The team is always entitled to do whatever they feel is correct and requires at the time. Especially a team should always shy anything that is common. Libraries, frameworks and any common component will only slow a team down. This is the mantra of many agile thought leaders.

Now, if you look at this in a short perspective and with only an isolated project I would agree. However if you are looking at this from cultural and a human level, I disagree. If ever team shy away from anything created by outsiders, how can you create a sense of community? A Not Invented Here on a team level will really hurt a company. It makes collective code ownership almost impossible of course.

Having a culture for collaboration does not equal a culture of building massive frameworks and over engineered architectures. I think it boils down to making choice based on the common good and not what is fastest or easiest right then and there. It is about taking into account how you can make things better for the next person being in your position. 

It is kind of like the boy scout principle on a team level. When a team encounters an issue: a library which is outdated, some code which needs refactoring or a module which isn’t quite generic enough for their use case. The team tries to see how they can improve it and still get things done. Naturally there will always be a balancing act, but the instinct should be to seek to improve the whole.

Never listen to thought leaders

The mantra of the thought leaders tend to be quite the opposite. They have one great enemy, the software architect. In order to conquer this nemesis they say that all developers should go choose what’s best for them and it will always be the best solution. To me, that is someone speaking who haven’t been staying with a company for very long. It is a short sighted approach, to instruct teams to build walls around them. That kind of strategy works really well for contractors and especially when you have fixed price or goal price style contracts. You deliver really quickly and reach your targets, without the slightest thought about those who’ll be living with that code when you’ve left. 

Embrace openness

Having a culture where teams embrace openness and which tries to reach out to improve the whole will prove beneficial in the long run. It will help you build an organization which will gradually improve and continuously build with better quality and quantity.