The Holy Grail of Code Sharing

Codesharing is a concept that is whispered in a low tone around the office, is being shouted loud by tools producers, and is simply misunderstood by the great part of us, IT folks.

Management people wish every single line of code to be shared and 100% reusable, they see only one single fact: less code means fewer costs.

Product Owners and Scrum Masters have big troubles in understanding why to put the time in code sharing practices, their way of thinking is: better done than perfect.

Developers… where do I start?
Oh yes, all we want is just to code and create amazing apps!

This is the story about how my team faced the challenge to improve code sharing among the company with the great objective to improve code quality, reduce time to market and create happier developers.

Our Problem

I work in a service company whose core business is mobile web applications development.

We sell development time to customers who know what, but not how to do business with mobile devices.

We are more than 100 programmers divided into teams of 6 to 10 guys. Each group is highly committed to its project and suffers under high time pressure to fulfill our different customer's expectations.

The projects around the company are not that different, we do tailor-based customizations of a shared service, much like a classic web agency producing custom websites.

Today there is close to zero code sharing around our teams and this fact costs us a lot of money.

We are a service company and our trading value is our developer's time.
When two teams solve the same problem in two different ways, they spend double of the time.

And when you sell services, the rule of thumb is fairly easy:
“the double the time the half the revenue”

To share code across teams appear to be the obvious and easy solution to our problem, but it turned out that it's not easy to really implement this in a proper way.

Our Struggle

Our product is a quite complex mobile web application so we proposed to split the requirements into smaller chunks that could be reusable and customizable by many teams.

We called those chunks Features and for the purpose of this article you can think to features as Login, Payment, Articles, …

A Feature is a quite big part of the entire application that implements a single responsibility like logging-in users or enabling payments, etc. It’s smaller compared to the whole application but still, it is an unfairly large piece of cake.

After some hard thinking we came up with a good understanding of the Features that were involved in our apps and we were extremely happy and proud when we proposed the company reorganize our developers into Feature Teams whose task is to implement a specific Feature to be reusable by others.

This solution was hard to hear and accept by management because it involved dramatic changes to the company’s structure and business model.

Feature Teams was just a dead end.

Our second approach was driven by the hard boundary to not change the company structure.
(We learned this lesson the hard way)

Long story short, we proposed to let our teams do their job and to create a side team of experts whose duty is to take existing custom code and change it to make it reusable.

Also this time, we became the target for jokes and laughter due to the concept of making things ”more reusable”. What does it mean? I still don’t know.

The third time you try, you are more likely to succeed.
If you are humble enough to learn from your mistakes.

Our Solution

Our final and most successful approach was to discard high academic thinkings and to go straight down to the core of our daily job.

we do not just write code,
we do solve problems with code!

So, instead of limiting ourselves to the struggle of code-sharing, we moved on and began to analyze where we were wasting time within the company.

The most time expensive moment in every developer’s day is called WTF.
(What The F**k)

This is not a bad or impolite expression. This is the technical name for the worst nightmare every man or woman involved in the process of solving problems with code may experience.

Our first action point was to put small and cross-team groups of developers into a room on a weekly basis with the only objective to share WTF stories.

To tell your mates where you had issues and how you solved those is not only about the code you wrote. It is all about the tools you used:

• search engines queries
• articles, books, blogs & forums
• colleagues that knew that s***

The second action point was to raise the culture of enterprise code writing.

Enterprise Code Writing is nothing more than a small group of best practices that we can use when it comes to writing code involving 130 people. Some of these are:

• single responsibility principle
• open source first
• readability first
• why » how » code

This bullet list might just sound like a bunch of cliché expressions, but I have to use them in this article, and actually, each of them is worth their own entire book.

The general principle that should drive each of us is:
Don’t do bullshit!

• to build a big module is way more expensive than building small ones that can work together
• to write my own DOM library is way more time consuming compared to using a jQuery custom build
• to write my own knowledge base about Javascript is just not the way, I can search, read and link valuable articles that are already available online

All those examples are surprisingly difficult to achieve when it comes to developers, the proudest and stubborn people on the planet!
(and as matter of fact I am proud to be one of them!)

Our Path

When it comes to practical coding we have a simple action point which is micro coding.

We left the idea of coding complete and reusable Features way behind us. Today we focus on writing the least amount of code possible for the smallest possible of the responsibilities. And we share that.

Each function, source file or module must solve one single problem, no more than one.

By just doing that our developers have begun to produce reusable code from the very first day of the change, without introducing any new tool in their chain.

In the beginning, we used a simple DropBox shared folder to share our micro libraries, today we have evolved a bit by introducing our second action point.

Our second practical action point is Open Source First.

If the solutions exists among the Open Source community we use it,
if we create our own solution, we publish it back for others to use.

Today we use CommonJS and NPM to write our Javascript, if we need a library we search NPM or GitHub, if it exists we use it, if it exists on GitHub but it is not available through NPM we contribute to the project to fix it, then we use it through NPM.

This behavior is much more than to merely give back to the community.

By actively publish open source code we get free help from the community that contributes to our repositories by doing bug-traking, bug-fixing and code enhancement.

For writing CSS we embrace the Object-Oriented CSS and we use LessCss to build them, to easily do cross-browser compatibility we have chosen LessHat which is quite simple and complete.

The third and most important action point was to challenge our developers.

There is nothing better than prizes to light up your willing of doing!

So we introduced cross-team challenges: groups of 3-4 people from different teams who were competing to produce some fun apps or little games.

The prize was always quite impressive and at the very beginning, some managers had a heart attack about that.

We have a play-room so we created a ChallengeME app to invite a colleague to the table tennis, we do afterwork so we suggested a PubRating app internal to the company… and much more!

Eventually, the learning effort that every developer put into the challenge was affecting the quality of his daily job so much that no money could have ever bought this accomplishment!

The best of it is that we exploited the proudness and stubbornness which is natural in each developer to play a fundamental and positive role within the company:

When a developer learn a better implementation he can not accept to see legacy code anymore so he/she coach other colleagues to improve. For free!

Don’t forget your Take Away!

Today my company is a better place to work and the quality of what we produce has increased greatly. We have really made some great accomplishments regarding code sharing and reusability.

We’re also planning to move more into a product business model, something we can do today because we now have the culture of enterprise coding and reusability built into every single one of our developers.

During the last year, a great guy left the company because his improvements were public on GitHub and he was head hunted by one of our direct competitors.

This is good, he will learn even more from them but he can not stop hanging out with us, his old mates, we have become real friends through this experience, so all of the knowledge is coming back to us!

We started this experience more than one year ago, we faced a problem, we spiked some dead ends but eventually we made it. It took some time but it was worth it.

What we have learned is that code sharing is not about tools, but about culture, is about people and knowledge, is about sharing the objective to spare some time from our daily struggles and to use it in a more fun and proficient manner.