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.

 

You and a million people other people can use the same chunk of knowledge without diminishing it.  In fact, the greater the number of people who use it, the greater the likelihood that someone will generate more knowledge with it.

 

- Alvin and Heidi Toffler from the book Revolutionary Wealth

 

The Tofflers are back with more futurism continuing their work from the Third Wave which was written in 1980.   I remember at the age of 12 reading Future Shock and all about information overload.  Coming from a small town in the Great White North of Canada, I had no idea what this meant.   Now I do.

 

But I digress, back to the quote above.  What does this have to do with software industrialization?  Everything actually.  In fact, thats the point of reusable software a chunk of software that is built upon another chunk of software that can be used by more people.  While I have accused our software industry of always writing software from first principles, commenters on this blog have pointed out that most always we write code on top of reusable frameworks or libraries.  While that is true, we still do write some of the same software over and over again (and one source code line at a time).  How many login dialogs have been written over and over again?  Customer classes?  Order classes?  You know what I mean, we are kinda stuck at a certain level of reusability where anything above framework or library code, we are back to writing code from first principles again.

 

I think the Tofflers quote also parallels Brad Coxs Software IC vision and specifically in his book, where we as programmers manufacture objects made of bits, but we still have not found a way to buy, sell and own them.  Brad has a solution which in many ways parallel what the Tofflers are talking about, yet, this industrialization of software has yet to mature to a point where it is a reality.  Aside from the distribution problem, which I will discuss in another post, I am interested in the reuse problem at the moment.

 

In my last post I discussed an idea around a design tool that reuses software components, or assemblies or classes, depending on how you see it.  Now I am going to discuss these ideas in the context of .NET as that is what I know the best, even though I have programmed in several languages (I do miss Smalltalk), I make a living as a .NET architect so this is the context I will use.

 

Lutz Roeder has a fantastic tool called .NET Reflector which is a "class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."  In some respects it reminds me a lot of a Smalltalk System Browser or Objective-C Browser.  The point being is that I can load any .NET assembly and effectively discern its design specification.  Why would I want to do that?  Well, if I want to reuse a piece of software, then I want to know what it has to offer so I can discern whether I want to reuse it or not.  Moreover, if I decide to reuse it, I need to know what methods, properties are available to me.

 

Where am I going to find reusable software?  Well, aside from the few catalogs that are available, Google (search) has the biggest reusable software catalog in the world.  So lets say I find some components that I want to reuse.  For example, the ubiquitous customer class or assembly.   I can add a reference to it in VS2005 and start using it, lets say in C#.  But then it is only one component (or class in this case) and I then I am back to writing single lines of code again.  No, what I am talking about is collecting as many reusable classes and/or assemblies that can solve a business problem and then composing my solution out of these assemblies.  In fact the design tool I am thinking of can assemble these assemblies dynamically.  Thats the other half of the design tool I am thinking of.  One half is disassembling components for their design specification and the other half assembling the components into a finished application.

 

This is why I am really excited about IronPython, a dynamic programming language that seamlessly integrates with the .NET Framework Class Library (and any other .NET assembly and COM object).  This means my design tool can glue classes together, subclass and essentially dynamically bind objects on the fly.  Now if I could that, then all of a sudden I got a real software design tool.

&nbs