The word scalability has long been used in software development circles to describe the capacity of a system to handle increasing load or demand. Software developers would assess the scalability of their applications by investigating both how well their application responds to increasing load with fixed resources and how well their applications take advantage of additional resources. The goal was to achieve perfect scalability also known as linear scalability.

Strictly defined, linear scalability, relative to load or demand, means that with fixed resources, performance decreases at a constant rate relative to load or demand increases. Linear scalability, relative to server resources, means that with a constant load or demand, performance improves at a constant rate relative to changes in resources.

Scalability in the Real World

That is all well and good, but it seems awfully academic. Why were software developers in corporate America dealing with this issue? Simply put, corporate America�s computing resources couldn�t keep up with the increasing load or demand that was placed on their applications. Software developers had no choice but to make scalability a priority when building their applications.

Vendors also fell victim to this same trend. If they wanted to sell enterprise software they had to make sure it was scalable. Their marketing departments got involved and soon every enterprise software application was touting its scalability. Religious wars ensued as vendors and software developers tried to show how much more scalable their applications were than their competitors.

Scalability and Language Selection

Much of the flak languages like VB and Java got were because of their perceived performance challenges. This led to a very typical comparison between software languages.

In the one camp, dominated by the language C, software developers would tout their language�s efficiency and pure speed of execution. The other camp dominated by languages like VB and Java, software developers would tout their ability to produce complex applications in significantly less time than that of their C counterparts. This debate still goes on today, but it is mostly moot because of the realities of the post dot-com era.

During the dot-com era money was flowing like water. Companies were

building applications to handle load or demands that seem very unrealistic

today, but seemed perfectly reasonable at the time. These companies bought the best equipment and people money could buy. When the money started drying up this method of software development dried up as well.

The New Meaning of Scalability

The new reality was simply learning to do more with less. Software developers needed to produce more functionality quicker than ever. There simply wasn�t time to make it scale. This forced many managers to start seriously looking at languages like VB and Java instead of C. Thus many software developers started using less efficient programming languages and paid little attention to scalability and more attention to functionality.

The funny thing was that many developers were finding that their applications were able to support greater demand than expected. So much more than expected, that managers were becoming less worried about the scalability of their applications and more worried about the scalability of their development teams. What caused this apparent change in attitude? A law that has governed the computer industry since its inception caused this change.

No need to rehash the now famous law proposed by Moore. The point is simply that while no one was looking, the computing resources in corporate America were growing faster than the demands put on them. It now cost less to buy a bigger machine than it does to build a more efficient program. Scalability has taken on a new meaning indeed.

Scalability of People, Not Applications

Today the word scalability is used more to describe the capacity of a software development team to handle increasing production requirements than the applications they produce. Instead of assessing applications, managers now asses the scalability of their development teams by investigating both how well their team can respond to increasing production demands with fixed resources as well as how well their team can take advantage of additional labor resources. It will be interesting to see what new development methodologies are used to help software development teams be scalable.