I remember in the mid 90s when software reuse was a big deal. Several books came out that discussed the need for software reuse and how to set up a reuse library in your organization. My favorite is, , by Will Tracz. One of the very few textbooks I have read that was as entertaining as it was useful.
10 years later I dont see much about software reuse at all. I dont find it as a topic of discussion on any programming related forums. Is it because we as computer scientists, software engineers, or programmers have institutionalized it as standard operating procedure or is it because the fascination we have over programming languages, software reuse is a forgotten practice?
Looking up software reuse
on Wikiepedia gets redirected to code reuse. This was a real surprise to me. I use Wikipedia quite a bit for software related information and it is usually is up to date and accurate. However, to equate software reuse with code reuse is missing the point of software reuse in general. I would define software reuse as the ability to leverage any existing software artifact that makes solving any software problem easier. Whether it is a project management schedule template to a fully blown domain specific language for automatically generating ecommerce solutions
would be considered software reuse in my book.
I know there are several libraries, SDKs, commercial components, etc., that come with your favorite programming language. Even K&R C from 1978
had this and probably even earlier before my time entering the computing world. The mid 90s also had the explosion of design patterns, the Gang of Four
being the most familiar to software designers and programmers. Today there is an incredible wealth of design patterns
. I am wondering if we ever use them? I must admit that while I have used some design patterns in a few projects and probably some unknowingly, I dont go out of my way to decompose my software designs into patterns, cause quite frankly, in my world of professional software development services, we never have time for such activities. My software development world is governed by the clock get it done as soon as possible.
So how do we implement reuse in our organization? In a nutshell, we Google it. Here is how it works. Our customer needs a custom web application built with certain functionality (what that functionality is does not really matter, because it has usually been done before). Our projects typically take on two distinct phases. Phase 1 is to write up a requirements specification, usually in the form of use cases and storyboards, all of which we have a library of templates which we reuse, including the statement of work, project schedules, etc. The customer signs-off and we are on to Phase 2.
Phase 2 begins with, what do we have from a previous project that we can reuse? That means any ASP.NET web pages, controls, components, custom assemblies that we have written before that we can leverage. For the pieces we dont have, we start our search with Google and other tools, looking in the usual suspect places where we know we can find example/sample designs and code that we can reuse in our overall solution. Since we are a Microsoft shop specializing in custom ASP.NET, SharePoint and just plain .NET applications, we know where to look. In fact, we have several links in our SharePoint library that points to our regular spots.
Once we have gathered all of the pieces, we look at what actual custom code is left to do. Surprisingly (or not) not much is left to do other than glue the pieces together and apply the paint. Now I make it sound easier than it is, but I would say on average that well over 50% of any custom development work we do is reusing pieces (on top of the .NET Framework Class Library) and in some cases as high as 80% software reuse. Just to be clear, we are a .NET shop only and we are not implementing or deploying packaged products, except in the case of SharePoint and then we only get involved in custom development using the APIs and/or page layout.
We have our test harnesses for unit testing, system testing, FxCop design and code coverage tests, performance and stress testing, bug tracking templates, etc. These are also reusable tool and template assets that we have accumulated and customized over the years. Some of the custom applications we have designed and developed handle over 1 million transactions per day that I think are good pieces of work. And others, well, you know, right? Since we have yet to reach a stage of industrialization in our software world, some projects are better than others.
So when does software reuse not work well? In our case it is the adoption of new technologies such as Microsofts SharePoint 2007 which just reached Beta 2. The problem here is that the architecture is so new that very little in the way of samples, examples or how tos has been developed. Here we are on our own, with little documentation, massively changed APIs and of course a Beta product.
What does this have to do with asking the question if we as the software community are reusing software? I guess thats the point. We seem to be doing it but when we are hiring new candidates (including seasoned professionals) only a few of them can point to reusing software and it usually is code reuse and even fewer have experience with design patterns. I cant believe we are the only ones doing it. But the friends I have in other software organizations also point to a very small percentage of software reuse in their own orgs. Why is that?
I dont think I have the answer to that question. I see that there is an international conference on software reuse
this year. Not sure who attends these. I wish I could go to Italy
Spending more time on Google does not help as most of the links to the subject matter in question are relatively old. It seems no longer a hot topic.
I would be interested to hear other peoples stories of software reuse. If you have a moment and would like to share, let me know. Thanks.