Reusing application code does have some risks and costs. However, reusability is a core best practices principle within software engineering and should be actively encouraged and pursued.
1-Software Reuse and Risks
Reusing Software does carry some risks. The main points of contention are below.
1.1-Code Quality of the original source code package
Code quality can be a major issue with reusing software packages. There is no guarantee that numerous syntactical or logical errors will not be found in reusing the code. Often, testing procedures are quite different between development teams, and if no standard approach is used, they can even differ between individual engineers. This could mean that there is a wide variation in code quality. As well, quality can relate to the code structure, its design and pattern of deployment, which may not be suitable for reuse. Usually some refactoring of code may be necessary, and this may generate unintended consequences and related errors in parts of the code package.
1.2-Lack of documentation in the original source code and outside (class diagrams, E-R schemas etc)
This is closely related to the above point but is an endemic problem in Software Engineering. Understanding complex packages can take time and though some automated tools exist to discover code syntax, meaning and structure; it will still be a long process of human intervention to properly understand and begin to conceptually arrange what the code is attempting to accomplish. Undocumented code also makes it very difficult to develop proper test cases to test the code.
1.3-Original code is not specific for the target platform
Code compatibility is a major obstacle to reusing older code packages. If you move older Visual Basic code to C# or .Net development, it is a long and tedious process to transform the lines of code into a more object-oriented code design. Automated tools do exist to help with this, but they must be augmented by human intelligence, requiring engineers who have a very good understanding of both the source code, and the target code. This refactoring can oftentimes, take much longer and be more expensive than de-novo coding.
1.4-Target platform and architecture has specific constraints which will mean extensive code refactoring and updating to the original source code package
Reusing code will determine your code base by default. However, the target platform requirements may mandate another programming approach. As well, there are tools and processes around the code development process which may demand a ‘newer’ code approach with for example, the use of Go, Ruby, Node.js or Angular. Or, testing tools may be better integrated with certain development processes and code repositories, and that automated pipeline is better suited with certain code bases. An example is the problem of using ‘DevOps’ tooling with Cobol. Though some tools exist for this, the typical use case for devops is to use modern code languages and proper CI-CD tooling. Reusing an old code base may hinder our ability to build proper automation.
2-Are there fewer risks today than 10 years, with software reuse?
It is easier today to reuse code. A significant feature of coding and packaging applications is the reuse of existing packages, patterns and code bases from repositories. Github, Git, SVN and other repos have complete application folders, open for reuse. A vast array of code bases are available. Most of these packages are worked on and tested, and there will be version control, comments and FAQs on how to use and deploy. Open source tools, including testing and integration tools, exist which can easily port or integrate code to different platforms.
The caveats mentioned above do apply, but reusing code, while it can have constraints and issues, is of course, a best practices principle within software engineering.