Thoughts on Software Reuse

Posted by ryan Sun, 14 May 2006 05:51:00 GMT

The January issue of Communications has an article entitled “Four Dynamics for Bringing Use Back Into Software Reuse” [1], in which the authors describe the results of their study which, they say, suggests that the level of software reuse within an organization differs across skill levels. Specifically, the authors say that those who reuse software components are generally “novices”, rather than “experts”. I would contend that, regardless of the fact that the authors’ conclusions are backed by the data from their study, they lack sufficient consideration of the different skill sets within software development, and how skill levels within these sets affect software reuse within an organization.

The authors of the study use the terms “novice” and “expert” to describe a developer with either a little or a lot of experience or skill in software development, respectively. By using these terms, however, it’s unclear if they are referring to “expert” in relation to a senior developer within the organization, within the industry that the organization belongs to, or whether they mean that an “expert” is a technically-skilled software developer. I have seen all three of these distinctions in my career as a software developer.

A senior developer within an organization would be considered an expert in the organization’s specific IT infrastructure, business rules, and so forth; this does not necessarily make the individual a skilled software developer, just knowledgeable about the organization for which they work. Such a developer is more apt to reuse components that are technical in nature, such as libraries for database systems, networks, graphics, etc. Additionally, in the case of open source libraries, senior organizational developers are less likely to contribute back to the libraries that they reuse. However, such developers are probably much more likely to build their own solutions to organization-specific problems, trusting in their extensive “private knowledge space” relating to the organization.

There are also industrial software development experts. These are people who have a rich set of knowledge about the regulations, software components, tools, and vendors involved in developing software for a particular industry. For example, a software engineer with expert knowledge in the banking or finance industry might have in-depth knowledge of leasing regulations, loan servicing, accounting systems, and others. Alternatively, someone with expert knowledge in the health care industry would have experience with associated EDI formats and HIPAA compliance. Such an individual is probably more likely to reuse organization-specific components to mitigate their lack of knowledge on that front, but may be involved in standards bodies or other initiatives for the industry in which they are considered an expert, and so may be more apt to develop custom solutions for such. The reuse situation for technical components may be similar to that of a senior organizational developer.

Finally, there are expert technical software developers. These are individuals who are skilled in functional decomposition, object-oriented development, design patterns, refactoring, programming languages, operating systems, testing techniques, and so on. An expert technical software developer understands the processes and techniques to develop quality software systems in general, independent of the industry or organization that they are working for. However, to have only technical skills is to lack the essential knowledge to correctly model for and develop systems in any particular industry. For this reason, developers with this kind of primary experience are less likely to build their own components to represent organizational business rules, infrastructure, and so on. However, they are much more likely to contribute to or build the technical components of a system, being that this is where their primary knowledge and skill lies.

A software developer will inevitably have some combination of the skill sets mentioned, and might be considered an expert in some aspect of one, two, or even (rarely, I suspect) all three of them. Regardless, I contend that the level to which each developer within an organization has skill in each set is a large differentiator in the level and type of software reuse that exists within an organization.


  1. Kevin Desouza, Yukika Awazu, Amrit Tiwana, “Four dynamics for bringing use back into software reuse,” Communications of the ACM, v.49, n.1, (January 2006): pp97-100.

Using a Version Control System 3

Posted by ryan Mon, 17 Apr 2006 18:58:00 GMT

The point of using a version control system (VCS) is to track versions of source files in a project, with the idea that building software is complex and it's often difficult to keep track of all of the changes that were made from one revision of a code base to another. If changes that were made cannot be tracked, there is no way to account for unforseen consequences of making a change to source code, such as breaking the build, failing QA regression tests, or negatively affecting performance. A VCS allows you to easily compare one version of a source file to another and figure out what you did to the latest revision, and to revert back to a previous version if necessary. It also allows large teams of developers to work on the same code base at once, by providing them with the ability to merge changes that they have made to the same source artifact, if necessary. For these reasons, the only things that should be checked into a VCS (as far as I can think of, anyways) are the buildable artifacts in a software development project, along with the non-buildable artifacts that the buildable artifacts depend upon.

Binary files that are not part of the build process are generally not a good fit for inclusion in a VCS, because it's difficult to see exactly what changed from one version to another, and nearly impossible to combine changes made to the same binary file by two or more people. This defeats the point of using version control to begin with. Another reason why binary files are not a good fit is that, with most version control systems (Subversion excluded), any minor change to said file results in an entirely new copy of that file being stored in the repository, along with any previous versions that might exist, and there is no way to reliably remove the previous versions of the file without removing all files that changed in that revision. This results in a nearly irreversably huge repository.

I've personally worked with CVS, Subversion, and SourceSafe. Of those, only SourceSafe allowed me to permanently delete individual files. However, this had a number of nasty consequences, mostly having something to do with SourceSafe not properly cleaning up references to deleted files and generally confusing itself, because SourceSafe sucks.

If you're free to choose the version control system you use, I'd highly suggest starting with Subversion. It's an offshoot of the older CVS, and addresses a number of shortcomings with that system. A comparison between CVS and Subversion can be found here. If you're using SourceSafe now, do yourself a favor and stop. Subversion is stable, mature, well-supported, well-documented, and open-source.