Software Evolution and Software Reusability

by Krishna on September 16, 2007

Software reusability has been the Holy Grail of the software industry. Managers and executives dream of the day when they can create software products by assembling software components like how houses and cars are built. Academicians have been predicting this for decades now. Still, we seem to be very far from such a state of reusability.

I don’t wish to say that no software is ever reused or that software programming is always done from scratch. However, the bulk of software reuse has to be the use of functionality within the software framework that is being used, such as the operating system, the run-time environment or a framework for web applications. In effect, generic APIs are the most common software reuse seen to date.

But, even there, we don’t see the “assembling” of software components to build products. The typical software development process involves a lot of custom coding. It is quite unlike having a lot of bricks and some cement to join them together. If anything, the process is more like having a few bricks and having to create the rest of the bricks.

One important factor is the rapid change in the fundamentals of building applications. Software environments keep improving very rapidly. Components built on older frameworks continuously face performance and software incompatibility problems. This is true at both the binary and source level. For example, a new operating system may not correctly support an older control’s hardware calls. Sometimes, it is just cheaper to rewrite an existing control than modify it to work with the new environment.

New software environments bring new functionality that makes existing controls obsolete. For example, there were a lot of software vendors making controls for Active Server Pages. When Microsoft came out with ASP.NET, some of them (like File Upload) became less useful. On the Java side, especially by Apache, new frameworks and libraries come up that replace many of the functions that you or other software vendors may have written.

New languages make older code really obsolete. Newer languages like Ruby and Python keep attracting larger number of followers. If you are migrating to a new language, the libraries and code that you have written in an older language become obsolete. You may be able to salvage some code by using methods like translation, web services and binary inter-operability. But as you lose your competency in the older language, it is a waste of time to keep maintaining the old code to keep up with business requirements.

Existing languages keep getting better. It is not your older brother’s C# or Java any more. Languages have been evolving at a much faster pace than ever before. It is almost like if you take a long vacation, the new language syntax can be incomprehensible once you come back. Backward compatibility does exist, but the new way of doing something is much easier and is better supported.

Supporting hardware and software keeps improving too. Today, desktop users have powerful multi-processor machines. Applications and controls could be re-written to take advantage of that. Database software also keeps improving in terms of new features for performance and ease of development. These are all areas where past code is probably not worth keeping around.

There have been revolutionary changes in computing paradigms. Recent developments and concepts like Ajax, RSS/Atom, mashups, cloud computing, etc. have changed the nature of software being developed. With Web 2.0, there has truly been an explosion in the number and quality of ideas about all aspects of software development including usability, performance, security, language design, etc. We are yet to sort this all out.

To conclude, I personally think that we are very far away from the assembly-line model of software development. There are too many fundamental revolutionary changes going on that it is very difficult to see that happen anytime soon. The only possibility of that happening is if software innovation stops happening, which is highly improbable.

{ 2 comments }

Mike Ramm September 17, 2007 at 1:44 am

Hi Krishna,

You are so right. When I was younger I believed that reusing code and components is the key to the successful software development and i always wrote my code with reusability in mind.

Later, I met Extreme Programming and I was initially shocked by their idea to write only what was requested and not to waste time in writing code that “might” be used sometime in the future.

Now I believe that thinking about reusability you must find the balance between writing everything from scratch and getting stuck to old technology. Which, of course, is very difficult but this is the mastery of our profession 🙂

Krish September 17, 2007 at 8:17 am

Yes, Mike. It is easy to be passionately for something, but to be able to understand various constraints and strike a balance is really difficult. But to be a good software practitioner, we have to learn how to do that.

Comments on this entry are closed.

Previous post:

Next post: