Code re-usability

My blog post about over architecture got quite a bit of attention. I have decided to expand on that topic and dig deeper into specific architecture related aspects.

“Before software can be reusable, it first has to be usable.” RALPH JOHNSON

Code re-usability seems to be a very hot topic for both business and developers alike. From my experience no one knows how best to write code that will be reused in the next project for one simple reason, what is the next project? We see quite a bit of re-usability happening in npm packages for node and react projects, jar files for android and of course pods for iOS development. Those are great examples of reusable code, but they are only this great due to someone else maintaining the library. In my experience one of the major issues of writing internal reusable code is lack of maintenance and knowledge transfer. Countless times I’ve heard developers tell me “using this code will take me longer then to rewrite it.” This specific logic goes totally against the whole point of re-usability.

One of the most successful experiments we had with reusable code is when we built a lightweight framework. The framework took care of simple things like localization, network layer, and navigation. The framework didn't stop people from doing network calls themselves but it offered an alternative that was one line to implement. We also enforced the framework as the base of any new project. One of the key elements of the framework was to use the latest version from latest working project. For one, it provides examples on usability, and secondly, each consecutive project fixes and augments the framework to become more robust. With time the idea is that you have a library of projects that provide real world examples of how to use the framework and you have multiple people that understand the flow of the framework and best ways to use it.

One of the main aspects of any reusable code is the ability to not use it. It is a choice given to the developer to make. No one forces people to use Math.pow function. You can simply do it yourself yet its there to simplify your code not enforce it. Other aspects include the ability for anyone to participate in the framework augmentation. This gives all developers participating in the framework more ownership of that framework. Giving ownership of the framework to the project, in which its being used, really helps the project succeed and most importantly, become the future automatic choice of base project.

We still can’t predict the next project but we know that having a framework that provides us with solutions to specific flows really helps. And when a new flow comes along we will add that new flow to the framework for future projects to use if needed. I totally foresee when the framework will become bloated and will be dragging along quite a few not used pieces, but I trust that smart developers on the project will slowly be taking those out just like they will be adding new things in. And yes sometimes that framework might not be the solution of a project but if anything it will be a great starting point for the project.

The last issue that remained was how to rip out the framework to make it a project base. We solved it by separating framework code from client specific code. So ripping the framework out really takes about half an hour of copying and deleting some folders. At the same time we can duplicate our Jenkins job to point to new repository; and suddenly we have a base build working, via the same Jenkins, to build a brand new project.

Re-usability really comes down to usability and knowledge transfer. Usability comes from simplicity and knowledge transfer comes from persistence.