During the Software Development Life Cycle (SDLC) the development team will come to realise that parts of any application have already been created before and there is the potential for those parts to be reused time and again going forward.
In the last few years, the culture of software development has moved towards Q&A sites such as StackOverflow to answer common daily problems that developers face. This has also led to many “Accepted Answers” being associated with these common issues and many developers have become quite indolent and simply copy/paste the code snippets directly from these types of websites straight into their application code they plan to ship. If and when it then resolves the problem they are facing, there is a high chance that the pasted code will eventually find it’s way into a production environment as is, or with very little change whatsoever.
Reinvention
Software reuse is inevitable and in most cases quite a positive thing. There is a saying: “don’t reinvent the wheel” which can be applied to almost anything, including software development (Douglas C. Schmidt, 1999).
Why would you recreate the same application code over and over if you have already created a decent working copy at a previous time? Surely it makes sense to simply just reuse that going forward?
These are questions that a development team face time and again and it is important to follow some sort of guideline so as to determine the correct time and place for code and or software reuse.
Assessments
In order to make a preliminary assessment so that some guidelines can be established, we can identify the key areas using the following three questions (Gregory Walter Hislop, 1993):
- Is a simple, single term functional classification adequate to describe existing software?
- Can analysis of software form locate similar (reused) programs in a software portfolio?
- Is there any discernable relationship between software form and function?
By knowing the answer to these three questions, we can propose a chart of reuse viability.
| Dependencies | Copyright | Viability |
| None | Allowable / None | High |
| Low | Allowable / None | High |
| High | Allowable / Unknown | Probable |
| Unknown | Not allowable / Patented | Dangerous |
Simplicity
It is fairly simple to reuse software parts, particularly if they are already modular or if they are standalone functions/methods that have limited or no dependencies.
Organisations often have many moving parts and it is advisable to take a look at Micro Services, which is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal (Tom Huston, n.d.). It is a proven way to be able to reuse entire modular sections of code as independent scalable entities.
References:
Douglas C. Schmidt – Why Software Reuse has Failed and How to Make It Work for You (1999) – Available from: https://www.dre.vanderbilt.edu/~schmidt/reuse-lessons.html
Gregory Walter Hislop – Assessing the potential for software reuse (1993) – Available from: http://dl.acm.org/citation.cfm?id=164193&preflayout=flat
Guideline: Software Reuse (n.d.) – Available from: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html
Tom Huston – What is Microservices Architecture? (n.d.) – Available from: https://smartbear.com/learn/api-design/what-are-microservices/