From fundamental to human, these are the factors that define the limits of technology:

• The laws of physics
• The laws of software
• The challenge of algorithms
• The difficulty of distribution
• The problems of design
• The problems of functionality
• The importance of organization
• The impact of economics
• The influence of politics

The Laws of Physics

Software is a flexible medium, but not so much so that we can ignore the laws of physics. In particular, the speed of light is a given, and that fact has pragmatic implications for distributed systems: Star Trek notwithstanding, you can't send a message faster than the speed of light. Furthermore, there are relativistic effects such that, across space, there is no such thing as absolute time. As a result, perfect time synchronization in a distributed system is impossible. Quantum effects also apply, meaning that there are theoretical and practical limits to information density: you cannot store more data than there are numbers of elementary particles in the universe. Finally, there exist thermodynamic effects. Although software itself is weightless, the containers that deploy software do have mass and therefore any computation conducted against the data in those containers will dissipate heat, a very pragmatic implication for any deeply embedded systems such as one might find in a spacecraft.

Back to top

The Laws of Software

Just as inviolate as the laws of physics, there are also some fundamental laws of software: relative to a given computation, sometimes we can't do it, sometimes we can't afford to do it, and sometimes we just don't know how to do it (these categories and their examples come from David Harel's delightful book, Computers, Ltd.).

Sometimes we simply cannot solve a problem. There exist a number of non-computable problems, such as the halting problem. Such problems are undecideable, because no algorithm can be followed to form a solution.

Sometimes we can't afford to solve a problem. Many problems, such as sorting a list of values, lend themselves to a variety of algorithmic approaches, each with varying time and space complexity. Some naive sorting algorithms run in quadratic times (meaning that their execution time is proportional to the square of the number of items to be sorted) whereas other, more sophisticated, algorithms run in logarithmic time. Such algorithms may be tedious but they are nonetheless still tractable. However, there exist other classes of algorithms whose time complexity is exponential. For example, the classic Towers of Hanoi problem as well as various graph traversal problems cannot be solved in better than exponential time. Such problems are considered intractable: they have an algorithmic solution, but their time or space complexity is such that, even with a relatively small value for N, running that algorithm would take centuries (or more) to complete.

Sometimes we just don't know how to do it. There exist a large class of problems -- finding the shortest path in a graph, trying to find the optimal means of packing a bin with various-shaped objects, matching class schedules to students and instructors, for example, that are tractable but NP-complete: we just don't know if these problems have better than an exponential time complexity. At present, the best we can do is seek optimal solutions, often by applying some simplifying assumptions or trying some more exotic approaches such as Monte Carlo methods, intense parallelism, or genetic programming.

These laws of software are demanding enough, but the problem is even worse as we consider the implications of non-continuous systems. For example, if we toss a ball into the air, we can reliably predict its path because we know that under normal conditions, certain laws of physics apply. We would be very surprised if just because we threw the ball a little harder, halfway through its flight it suddenly stopped and shot straight up into the sky. In a not-quite-debugged software simulation of this ball's motion, exactly that kind of behavior can easily occur.

Within a large application, there may be hundreds or even thousands of variables as well as multiple threads of control. The entire collection of these variables, their current values, and the current address and calling stack of each process and thread within the system constitute the present state of the system. Because we execute our software on digital computers, we have a system with discrete states. By contrast, analog systems such as the motion of the tossed ball are continuous systems. Parnas suggests that "when we say that a system is described by a continuous function, we are saying that it can contain no hidden surprises. Small changes in inputs will always cause correspondingly small changes in outputs." On the other hand, discrete systems by their very nature have a finite number of possible states; in large systems, there is a combinatorial explosion that makes this number very large. We try to design our systems with a separation of concerns, so that the behavior in one part of a system has minimal impact upon the behavior in another. However, the fact remains that the phase transitions among discrete states cannot be modeled by continuous functions. Each event external to a software system has the potential of placing that system in a new state, and furthermore, the mapping from state to state is not always deterministic. In the worst circumstances, an external event may corrupt the state of a system, because its designers failed to take into account certain interactions among events. For example, imagine a commercial airplane whose flight surfaces and cabin environment are managed by a single computer. We would be very unhappy if, as a result of a passenger in seat 38J turning on an overhead light, the plane immediately executed a sharp dive. In continuous systems this kind of behavior would be unlikely, but in discrete systems all external events can affect any part of the system's internal state. Certainly, this is the primary motivation for vigorous testing of our systems, but for all except the most trivial systems, exhaustive testing is impossible. Since we have neither the formal mathematical tools nor the intellectual capacity to model the complete behavior of large discrete systems, we must be content with acceptable levels of confidence regarding their correctness.

Back to top

The Challenge of Algorithms

As the previous section indicated, there are certain classes of problems that are tractable yet exponentially complex. There also exist other tractable, albeit larger, problems for which we can glimpse a solution but for which we have not yet settled on a reasonable algorithm: data compression and photorealistic rendering are two such problems.

In the case of compression algorithms, we can state the theoretical limits of compressing an image, a waveform, video, or some raw stream of bits, but even so there are a myriad of choices if we allow some degree of information loss. The more we know about the use and form of the information we seek to compress, the closer we can get to this theoretical limit: it's largely a bit of hard work, some hairy mathematics, and some trial and error to find a suitable compression algorithm for a given domain.

In the case of photorealistic rendering, the field is also characterized by hard work, hairy mathematics, and some trial and error. A few decades ago, it was quite an accomplishment just to model pitchers and cups -- and even then, the results looked artificial and plastic. Today, the field has gotten much better -- we can model scenes down to the level of individual hairs on a beast and we can do a fairly good job of biologically real movement. However, rendering human faces, ice, and water is not quite to the point where a careful observer can be fooled. There will likely come a time when we can do all these things, and when we do, the solution will look simple, but in the meantime, our lack of perfect knowledge adds complexity and compromise to our systems.

Back to top

The Difficulty of Distribution

When we think of an algorithm, we typically think of a flow of control that weaves its way through a single pile of code living on exactly one processor. However, when we think of systems, it's rare to find one that is so isolated that it stands apart from all others. Make no mistake about it: building a distributed system is materially harder than building a monolithic one. As Leslie Lamport once observed, "A distributed system is one in which the failure of a computer you didn't even know existed can render your computer unusable."

We'd like to believe that building distributed systems is only moderately harder than building a non-distributed one, but it is decidedly not, because the reality of the real world intrudes. As Peter Deutsch once noted, there are eight fallacies of distributed computing: we'd like to believe that these are all true, but they are definitely not:

• The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
• Topology doesn't change
• There is one administrator
• Transport cost is zero
• The network is homogeneous

The fact that these elements are not true means that we have to add all sorts of protocols and mechanisms to our systems so that our applications run as if they were true.

Back to top

The Problems of Design

Simplicity is an elusive thing. Consider the design of just about any relevant Web-centric system: it probably consists of tens of thousands of lines of custom code on top of hundreds of thousands of lines of middleware code on top of several million lines of operating system code. From the perspective of its end users, simplicity manifests itself in terms of a user experience made up of a small set of concepts that can be manipulated predictably. From the perspective of those who deploy that system, simplicity manifests itself in terms of an installation process that addresses the most common path directly while at the same time makes alternative paths accessible and intuitive. From the perspective of the developers who build that system, simplicity manifests itself in terms of an architecture that is shaped by a manageable set of patterns that act upon a self-consistent, regular, and logical model of the domain. From the perspective of the developers who maintain that system, simplicity manifests itself in the principle of least astonishment, namely, the ability to touch one part of the system without causing other distant parts to fall off.

Simplicity is most often expressed in terms of Occam's Razor. William Occam, a 14th-century logician and Franciscan friar stated, "Entities should not be multiplied unnecessarily." Isaac Newton projected Occam's work into physics by noting, "We are to admit no more causes of natural things than such are both true and sufficient to explain their appearances." Put in contemporary terms, physicists often observe, "When you have two competing theories which make exactly the same predictions, the one that is simpler is the better." Finally, Albert Einstein declared that "Everything should be made as simple as possible, but not simpler."

Often, you'll hear programmers talk about "elegance" and "beauty," both of which are projections of simplicity in design. Don Knuth's work on literate programming -- wherein code reads like a well-written novel -- attempts to bring beauty to code. Richard Gabriel's work on the "quality with no name," building upon architect Christopher Alexander's work, also seeks to bring beauty and elegance to systems. In fact, the very essence of the patterns movement encourages simplicity in the presence of overwhelming complexity by the application of common solutions to common problems.

The entire history of software engineering can perhaps be told by the languages, methods, and tools that help us raise the level of abstraction within our systems, for abstraction is the primary means whereby we can engineer the illusion of simplicity. At the level of our programming languages, we seek idioms that codify beautiful writing. At the level of our designs, we seek good classes and in turn good design patterns that yield a good separation of concerns and a balanced distribution of responsibilities. At the level of our systems, we seek architectural mechanisms that regulate societies of these classes and patterns.

The difficulty of design, therefore, is choosing which design and architectural patterns we should use to best balance the forces that make software development complex. To put it in terms of the laws of software, this general problem of design is probably NP-complete: there likely exists some absolutely optimal design for any given problem in context, but pragmatically, we have to settle for good enough. As we as an industry gain more experience with specific genres of problems, then we collectively begin to understand a set of design and architectural patterns that are good enough and that have proven themselves in practice. Thus, designing a new version of an old kind of system is easier, because we have some idea of how to break it into meaningful parts. However, designing a new version of a new kind of system with new kinds of forces is fundamentally hard, because we really don't know the best way to break it into meaningful parts. The best we can do is create a design based upon past experiences, plagiarize from parts that worked in similar kinds of situations, and iterate until we get it good enough.

Back to top

The Problems of Functionality

Consider the requirements for the avionics of a multi-engine aircraft, a cellular phone switching system, or an autonomous robot. The raw functionality of such systems is difficult enough to comprehend, but now add all of the (often implicit) nonfunctional requirements such as usability, survivability, and adaptability. These unrestrained, potentially contradictory, external requirements are what form the arbitrary complexity about which Brooks writes. This external complexity usually springs from the "impedance mismatch" that exists between the users of a system and its developers: users generally find it very hard to give precise expression to their needs in a form that developers can understand. In extreme cases, users may have only the vaguest ideas of what they want in a software system. Moreover, developers may not even know exactly the expectations of its user base, especially in the case of emerging, rapidly changing markets. This is not so much the fault of either the users or the developers of a system; rather, it occurs because each group generally lacks expertise in the domain of the other. Users and developers have different perspectives on the nature of the problem and make different assumptions regarding the nature of the solution. Actually, even if users had perfect knowledge of their needs, it is intrinsically difficult to communicate those requirements precisely and efficiently. At one extreme, the development team may capture requirements in the form of large volumes of text, occasionally accompanied by a few drawings. Such documents are difficult to comprehend, are open to varying interpretations, and too often contain elements that are designs rather than essential requirements. At the other extreme, there will be no stated requirements, only general visions. This may work for exploratory development, but it is absolutely impossible to manage a development process against invisible requirements.

A further complication is the fact that, for industrial-strength software, there are typically a large number of stakeholders who shape the development process, most of whom are completely unimpressed by the underlying technology for technology's sake. These stakeholders will bring to the table a multitude of hidden and not-so-hidden economic, strategic, and political agendas that often warp the development process through the presence of competing concerns.

For software that matters, the requirements of a system will typically change during its development -- not just because of reasons of technology churn or resilience -- but also because the very existence of a software development project alters the rules of the problem. Seeing early products, such as design documents and prototypes, and then using a system once it is installed and operational, are forcing functions that lead users to better understand and articulate their real needs. At the same time, this process helps developers master the problem domain, enabling them to ask better questions that illuminate the dark corners of a system's desired behavior.

Because a large software system is a capital investment, we cannot afford to scrap an existing system every time its requirements change. Planned or not, large systems tend to evolve continuously over time, a condition that is often incorrectly labeled software maintenance. To be more precise, it is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation. Unfortunately, experience suggests that an inordinate percentage of software development resources are spent on software preservation.

Back to top

The Importance of Organization

Size is no great virtue in a software system. In design, we strive to write less code by inventing clever and more powerful mechanisms that yield the illusion of simplicity, as well as by reusing patterns and frameworks of existing designs and code. Indeed, at the limit, the best way to reduce the risk of a software development project is to simply not write any code at all. However, the sheer volume of a system's requirements is often inescapable, forcing us either to write a large amount of new software or to glue together existing software in novel ways. Just three decades ago, assembly language programs of only a few thousand lines of code stressed the limits of our software engineering abilities. Today, it is not unusual to find delivered systems whose size is measured in hundreds of thousands, or even millions of lines of code (and all of that in a high-order programming language, as well). No one person can ever understand such a system completely. Even if we decompose our implementation in meaningful ways, we still end up with hundreds and sometimes thousands of separate components. This amount of work demands that we use a team of developers, and ideally, as small a team as possible. Furthermore, for software systems that drive an entire enterprise, one typically must manage teams of teams, each of which may be geographically distributed from one another. More developers mean more complex communication and hence more difficult coordination, particularly if the team is geographically dispersed. With a team of developers, the key management challenge is always to maintain a unity and integrity of design. In the small, agile approaches to development leverage the social dynamics of the small, hyper productive team. In the medium and large, however, you need more control because the stakes are higher and the paths of communication among stakeholders is far more complex.

In contemporary software development organizations, the problem is made worse by the reality that the complete development team typically requires a large mix of skills. For example, in most Web-centric projects, not only do you have your typical code warriors, but you often have a set of them who speak different languages (e.g. HTML, XML, Visual Basic, Java, C++, C#, Perl, Python, VBScript, JavaScript, Active Server Pages, Java Server Pages, SQL, and so on). On top of that, you'll also have graphic designers who know a lot about HTML and technologies such as Flash, but very little about traditional software engineering. Database administrators and security managers will have their own empires with their own languages, as will the network engineers who control the underlying hardware topology upon which everything runs. As such, the typical development team is often quite fractured, making it challenging to form a real sense of team.

Not only are there issues of jelling the team, there are also points of friction from the perspective of the individual developer, friction that eats away at the individual's productivity in subtle ways. Specifically, there exist the following points of friction:

• The cost of start up and on-going working space organization
• The schedule and mental impact of work product collaboration, including the energy spent in negotiating with different stakeholders
• The friction of maintaining effective group communication, including the sharing of knowledge, project status, and project memory
• Time starvation
• Time lost from software and hardware that doesn't work

We call these points of friction because energy is lost in their execution which otherwise could be directed to more creative activities that contribute directly to the completion of the project's mission.

Thus, all meaningful development is formed by the resonance of activities that beat at different rhythms: the activities of the individual developer, the social dynamics among small sets of developers, and the dynamics among teams of teams. Much like the problem of design, finding the optimal organization at each of these three levels and deciding upon the right set of artifacts for each to produce using the best workflows is challenging, and is deeply impacted by the specific forces upon your project, its domain, and the current development culture. To some degree, every team is self-organizing -- but always within the structure imposed and encouraged by its context, and that means the organization as a whole and its management. Choosing that organization structure is not a technical problem, but instead is a human problem, which by its very nature is complex. As a human problem, there are naturally all the usual human dramas that play out, often amplified by the stresses of development. Ultimately, however, what drives the structure of an organization are its surrounding economics.

Back to top

The Impact of Economics

Developing software costs money. Barry Boehm, in his classic work on software engineering economics, based upon 20 years of empirical evidence, concludes that the performance of a project can be predicted according to the following equation:

Performance = (Complexity**Process) * Team * Tools

where

From this equation, we can observe that the complexity of a system can either be amplified by a bad process or dampened by a good process and that the nature of a team and its tools are equal contributors to the performance of a project.

During the dot com mania around the turn of the millennium, software economics was pretty much ignored -- and thus contributed to the dot bomb collapse. Developing software costs money, and thus for any sustainable business activity, any investment in software development must provide a good return on that investment. Thus, we might dream up suspicious uses of software that have no fundamental economic value, but to do so will ultimately end in economic collapse. Alternatively, we might dream up meaningful uses of software, and to the degree we can develop that software efficiently and use that software as a strategic weapon in our business, the effort will yield business success.

Back to top

The Influence of Politics

Speaking of success, the degree to which success as defined by the software development team is misaligned with success as defined by the organization is a measure of that organization's dysfunctionality. Sometimes, an organization will use software as a pawn, putting its developers on a death march and sacrificing their health for the short-term good of the company. That's an approach that will quickly burn out your development team. Other times, the organization will be clueless as to how it can leverage its software resources. That's an approach that will, over time, undermine the morale and value of the development team.

In the best of worlds -- which unfortunately is a fairly narrow space -- an organization will leverage its investment in software development so that software is in fact a strategic weapon for the company. Anything less and the software development team will be limited in the great things it could have provided.

(The article is excerpted from the forthcoming third edition of Object-Oriented Analysis and Design with Applications).

About the author

Grady Booch is recognized internationally for his innovative work on software architecture, modeling, and software engineering processes. All of his work has improved the effectiveness of developers worldwide. Grady is one of the original developers of the Unified Modeling Language (UML) and was also one of the original developers of several of IBM Rational products including Rational Rose, the industry-leading visual development tool. Grady is the author of six best-selling books, has published several hundred technical articles on software engineering, and has lectured and consulted worldwide. Grady served as Chief Scientist for Rational software.

Rate this article

Comments

Back to top

Table of contents

• The Laws of Physics
• The Laws of Software
• The Challenge of Algorithms
• The Difficulty of Distribution
• The Problems of Design
• The Problems of Functionality
• The Importance of Organization
• The Impact of Economics
• The Influence of Politics
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Rational on developerWorks

Discover knowledge paths

Skill-building guides for Rational, Linux, open source, cloud, Java, business analytics, and more.

Special offers