LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Guest View: A discontinuous jump


By Charles W. Krueger
March 15, 2009 — 
For an engineer, creating a dishwasher is more fun than washing dishes. Creating a car to take you places is more exciting than walking or running. Creating a factory to assemble cars is an even more interesting challenge than assembling cars.

The drive to create new and improved tools is an innate part of the human condition, hard-coded into our DNA. We are never quite happy with the current state of affairs and are always looking for ways to create new tools that minimize our labors and maximize our wellbeing, relaxation and recreation.

The historical timeline for our tool capabilities progresses through continuous and incremental improvements, with an occasional discontinuous jump. That term comes from calculus where, for our tool example, a smooth increasing graph reaches a point of discontinuity, makes a vertical stair-step jump, and then continues again as a smooth increasing graph. Discontinuous jumps in the context of tools arise from pivotal discoveries that lead to paradigm shifts.

Archeological indicators of discontinuous jumps in tools can be seen in the concentric fortifications around ancient cities. Smaller inner walls are circumscribed by taller and thicker walls, then encircled by huge earthen embankments and trenches. Each concentric layer demarcates a point in time where there was a discontinuous jump in the tools of war that rendered the previous fortifications obsolete.

Most software engineers—at least those not yet of retirement age—have never experienced a discontinuous jump in our tools and methods. Good news: That situation is at long last about to change.

The software engineering field has exhibited a rather monotonous timeline of continuous and incremental improvements in our tools and methods, with only one notable discontinuous jump in our 60-plus-year history. That event occurred over 50 years ago, when high-level languages and compilers supplanted low-level binary and assembly language programming to reduce the program statement count by approximately a factor of 20, and software delivery time and effort by approximately a factor of 5.

Of course, this rather mundane reality hasn’t dampened the spirits of our marketing teams. They are still having their fun with claims of order-of-magnitude improvements. But if you look beyond the anecdotal evidence and individual case studies, the software field has not experienced an across-the-board discontinuous jump since the advent of Fortran and COBOL compilers.

In his widely cited article, "No Silver Bullet: Essence and Accidents of Software Engineering,"Fred Brooks argues convincingly that the lack of discontinuous jumps in software engineering is a predictable and fundamental characteristic of creating software. Although we expect continuous incremental improvements in the way we express problems that we solve with software, Brooks argues that the complexity of these problems remains relatively constant—and very high. We can never reduce this essential complexity, and it determines the lower limit on how quickly we can express a solution through software.

In spite of Brooks’ 1987 prediction, two forces are at play today in creating a new discontinuous jump in software engineering. The first of these forces is in the problems we are asked to solve. It is in the prevalent demand for most software and software-based system companies to create and maintain larger and larger product lines—portfolios of similar products with variations in features and functions—rather than just individual one-of-a-kind products. Using traditional development tools and methods, the complexity of developing a product line grows proportionally to the square of the number of products (or, order-of-N2). As a result, the complexity of engineering our expanding product lines is outpacing the linear incremental improvements of our software tools and methods.

The second of these forces is in a new approach in software tools and methods for engineering product lines, referred to as software product lines. A new generation of SPL tools and methods has constrained the complexity of creating and maintaining a product line from order-of-N2 to a linear order-of-N. The result is a consistent twofold to tenfold improvement in software development metrics like productivity, defect density, time-to-market and portfolio scalability. In other words, a discontinuous jump.

This raises a few important questions.

In light of Brooks’ longstanding prediction that we wouldn’t see such an across-the-board discontinuous jump of improvement in software engineering tools and methods, how is this possible? There is an implicit assumption in Brooks’ argument that the complexity of the problems we solve with software will evolve slower than the capabilities of the tools we use to solve them. The expanding product line problem, with its order-of-N2 complexity growth, invalidates this assumption, inducing a rapid increase in a new type of complexity for most organizations and opening the door for pivotal discoveries and innovations.

What is the key ingredient of an SPL solution that allows for the dramatic reduction in complexity compared to traditional software tools and methods? Traditional approaches and even early-generation SPL approaches tend to take a product-centric view, where every defect fix or requirement enhancement on any product in a product line may need to be reflected similarly in other products in the line. This interdependency among all products leads to the order-of-N2 complexity.

New-generation SPL tools approach a linear order-of-N complexity by exploiting a manufacturing approach to creating and maintaining a product line. It is very similar to engineering a single automated production line for automobile manufacturing. The assets that comprise the products, and the automated production tools that assemble and configure the products, are engineered as a single system rather than a multitude of products. The products themselves are demoted to a secondary side effect of the manufacturing system.

A defect fix or enhancement intended for any particular product is performed on the entire system of assets as well as the automated production capability, such that they can be automatically applied to any or all products. You can eliminate the order-of-N2 relationship between products by taking this single-system perspective.

As a colleague once observed, the right point of view saves 20 points of IQ.

The exciting thing about discontinuous jumps is that they open up new frontiers, offering new possibilities and challenges that could not even be conceived of in old paradigms. What new challenges and opportunities lie ahead in the new frontier of SPL engineering?

As the civil engineers who built the ancient cities did, the first thing to note is that paradigm shifts can be used against you as well as to your benefit. The first challenge you see may come from your competitors who make the shift before you do.

Another challenge is that organizations do well with continuous and incremental improvements, but may not with paradigm shifts. This is particularly true in software engineering since we haven’t experienced discontinuous jumps, and therefore we haven’t established a culture that is accepting of paradigm shifts.

I’ll leave it to your imagination as to how your business and engineering organization could take advantage of a discontinuous jump that offered you two- to tenfold improvements in productivity, reaction time for new market opportunities, portfolio size and product diversity. What if the scale, scope and diversity of your product line were only limited by the imagination of your organization rather than by the capacity of your engineering team?

Charles W. Krueger is founder and CEO of BigLever Software, which sells tools for managing software product lines.


Related Search Term(s): software development


Share this link: http://www.sdtimes.com/link/33332
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading