“In-house” open source – code reusage can be your friend

Introduction

A big problem nowadays when dealing with large-scale software projects is deciding upon reusing existing code or designing a fresh chunk of code that would do approximately the same thing. At a first glance the decision should clear and code reuse should be chosen. However, there are a couple of strong arguments that back up both decisions.

In this article we will illustrate some of these drawbacks of both approaches and propose a trade-off solution that would improve code quality and time management within a large software company. We will then present the potential improvements in contrast with the challenges that such a solution would pose.

Background

A large project is usually split into smaller, more manageable chunks, which are able to be developed separately and integrated afterwards, with specific requirements outlined at the beginning. This being said, when developing a sub-task of the project, the algorithms/methods that compose that sub-task are usually not new concepts, but rather, a rearrangement of them in order to produce different results.

This being said, when looking at the two options available (reuse or design from scratch), the first one would be the best solution as it should be less time-consuming and less intellectual effort would be wasted on things that are already developed. However, the code that is to be reused is usually developed by another developer and this represents one of the challenges as we will see next.

Developers are very different when it comes to designing and implementing code. Usually the code of another person is harder to read while understanding the whole extent of its functionality than to redesign new code. This is why, code re-usage is often regarded as a more difficult and messy approach and the second choice (designing of new code) is mostly regarded as preferable.

A solution to this problem would represent software maintenance and well-documented code. However, given the probability of a developer to reuse his own code (a low one), little effort is put in making the structure and line of thought very clear. In most of the cases the code will never be reused and in the best case it will only serve for mild inspirational purposes.

We will now present a comparison between the two approaches together with their advantages and drawbacks in order to get a better idea about what can be improved.

The two Rs: Reusing vs. Redesigning

When considering a task it is very common to divide it into small “atomic” chunks and deal with them separately. Most of the software programs that are currently developed have a lot of these “atomic” chunks in common. Re-usage of existing code would save a lot of time when dealing with familiar or already developed parts. However, the code that is to be reused is usually not in a very friendly form and has to be refactored and adapted to the current set-up.

On the other side, redesigning everything from scratch is viewed as easier and more convenient, given the level of concentration needed to identify potential flaws and inconsistencies in the existing code when trying to integrate it with the rest of the project. A new, clean version of the required code would allow a better overview of it from the developer and can work towards better understanding of the underlying structure and hidden advantages. The down side of this is, as mentioned before, time wastage. Whenever redundant work is performed, time is considered to be wasted.

A mix between the two would significantly improve code quality and time management within a large software company.

In-house open source – better code quality

First we will define the concept of “in-house” open source and then proceed with describing the underlying aspects and additional measures that would be implemented in order to produce quality code and encourage re-usage.

This type of open source refers to the source code that is made available within a large software company. We can look at it as an intranet or a private public code pool. The idea is to focus on a smaller group of developers that can be motivated to create code which not only satisfies the project-wise requirements but also is “friendly” enough to be reused.

A database would have to be setup in order to hold all these reusable chunks. We can look at it as a virtual code library where each “atomic” chunk falls into a category and/or has specific tags that make it identifiable with a given task.

Also, in order to motivate the people involved in creation and re-usage, incentives must be provided. We will consider the initialization of such a system and potential evolution.

In the beginning all code will have to be new, in order to secure the quality of it. The chunks that are identified as being general and reusable would be well documented and structured. At this stage, extra work is required from the developers as they have to perform two tasks instead of one. However, once the code library starts to be populated, the advantages of such an approach would start to show. We now consider that the code library has a considerable size. When dealing with new projects, developers now would have to work less than average, given the re-usability of existing code.

In order to set-up such a system some methods of motivating are required. If extra work would not have any advantages the drive to work towards a common goal would disappear. An internal referencing system would solve the acknowledgement issue while a bonus-driven system would address the incentive problem.

Advantages and challenges of the approach

To sum up the discussion presented above we will identify some of the aspects that the proposed approach aims to address and improve together with eventual challenges that it may encounter.

  • the initial development part is the most important and the most difficult: new code is being created that has to be both functional for the current task and reusable. The second property can prove to be the most challenging part as the code must be read and understood with ease from an objective point of view (another developer)
  • once the library is set-up, it will serve the developers with good quality reusable code and thus will spare them a lot of time that would have been otherwise spent on redundant development.
  • the efficiency of the approach is direct proportional with time passage and size of the company.
  • more time in the long-run would allow developers to focus on the key aspects of an idea/algorithm and deliver better quality code
  • bonuses awarded to developers that are being “cited” means that they are motivated to produce even more reusable content
  • when considering the company’s success there are two possible leads: either keep the library private and thus increase efficiency and delivering rate or make the library available for purchase with the trade-off that the advantage is lost.

Conclusion

Even though code re-usage can be viewed as an improbable action when dealing with new projects, given the right circumstances and set-up, it can prove to be a very powerful tool and count towards improving the efficiency of the whole company that promotes it.