"Software is hard."
                                       --Donald Knuth


This opening chapter provides context and motivation for learning about better methods of software development. In short, it tells the story outlined in figure 1. The demand for dependable software is strong, and growing at a rapid pace. At the same time, average industry performance is unenviable. Especially worrisome are spectacular failures-- those that have occurred in the past and the prospects for even more serious ones in the future. It doesn't have to be this way though. Despite the high average failure rates for the industry as a whole, there are organizations that routinely deliver quality software according to predictable schedules and budgets. The question is how?

Figure 1. Chapter Roadmap

The Demand for Software is Strong and Growing

Software is pervasive throughout our economy and culture. Nearly all products and services that power the industrialized world depend on software.

[Today's large-scale software systems are among the most complex structures ever built by humans. Take away the qualification "built by humans" and the only systems that clearly exceed software systems in complexity are biological systems. OR?

Today's large-scale software systems are the most complex artifacts ever built by humans, second only to biological systems in their complexity. Remove the qualifier "built by humans" and software system are second only to biological systems when it comes to (the all-time hit parade of complex artifacts) complex structures/artifacts*. (*This assessment is based on the weighted number of distinguishable pieces from which systems/artifacts are constructed. of artifacts that are in the running. For example, the Eiffel Tower (no relation to the Eiffel programming language) has 2.5 million rivets. These contribute less complexity to the overall monument because they are visible and repetitive. In terms of contributed complexity, 2.5 million rivets aren't comparable to 2.5 million lines of code. They might be comparable to straight line code initializing the elements of a an array one-by-one, but not the lines of code found in the typical large-scale program.]

Today's large-scale software systems are the most complex human artifacts ever created, second only to biological systems in their complexity.]

Take for example the auto industry and their products. The average luxury car today contains close to 100 million lines of code [This car runs on code]. One hundred million of anything is hard to imagine, but software is especially hard to imagine because it's intangible. You can't see or touch software directly. You can only experience its effects indirectly through a machine's behavior.

Thankfully software doesn't have to be kept in a tangle form when in use. Printed and bound, 100 million lines of code weighs over 3,000 lbs. That's significantly more than the towing capacity of a BMW 7-series. Put another way, printed out, the software contained in a premium automobile is enough to fully cover a two-lane highway for 13.5 miles. Just image what it would be like walking this highway looking for a defect somewhere in the code. Because it's invisible, most people don't realize just how much their everyday experiences depend on the effective operation of software.

Not only is there a lot of software in use today, the amount of software in products is growing at a rapid rate. Figure x shows the growth rate of lines of code in space systems and department of defense weapon systems from 1960 to 1995. Notice the logarithmic scale along the y-axis. The slope of the regression analysis lines in the graph indicate that the amount of software contained in the space and weapon systems shown has been growing exponentially for over 30 years.

[Ref: chapter 1 from Guidelines for Successful Acquisition and management of Software-Intensive Systems read later]

Demand for software has been strong since the first general-purpose programmable computer was first introduced in the 1960's. Demand is expected to remain strong on into the foreseeable future. Here are a few of the major forces that are driving demand for software today:

Moore's Law. Moore's law has been a friend to the technology industry for a long time. As hardware gets cheaper and capacity grows, it paves the way for more affordable devices and larger more complex software systems. Old applications become more economical and available to a wider audience. New applications start to become technically possible and economically feasible.

Moore's Law

In 1965 Gordon Moore of Intel observed that the number of transistors per integrated circuit doubled about every year. Since he made this observation the doubling period has "slowed" to 18 months. The consequence is that every 18 months storage/computing capacity doubles or costs are cut roughly in half.

Software replacing hardware. At the same time hardware advances are increasing opportunities for more software, software is steadily replacing hardware in many applications. The following table shows software growing from 8% to 80% of major weapon systems over 40 years.

[Ref: Crouching dragon, hidden software: software in DoD weapon systems, IEEE Software]

The Mars Rover offers another dramatic example of the advantages of software over hardware. In 2004 NASA was able to fix a problem with a feature implemented in software on the Mars rover while it was 100 million miles from earth. Had the feature been implemented in hardware, it would have required a very expensive service call.

Better performance, the main reason to prefer a hardware solution over a software solution, isn't always a given. Sometimes software beats hardware in terms of flexibility and performance. For example, binary translation, the software solution to operating system virtualization, is sometimes faster than trap-and-emulate, the hardware solution to virtualization [Modern Operating Systems, Tanenbaum, 2008, p573].

Product differentiation with software. Software is increasingly being used as a differentiator in many products and services. Competition is fierce and profit margins narrow on commodity products. Increasingly software is being used to add unique features to products and services less they become a commodity. For example, cell phone companies that compete on price-per-minute have very low profit margins. Rather than compete strictly on price-per-minute cell phone companies are adding features with software (text messaging, pictures, email, etc) that differentiate their product and service and make it less vulnerable to commodity price wars. Increasingly, the features that make one cell phone better than another comes more from the software services implemented on the phone than hardware or network aspects.

[tbd: insert audio segment from the tech guy 1/9/2010]

Open source. From the beginning, software has offered tremendous opportunity to entrepreneurs. Anyone with with a computer, a compiler, training and enough time can build any software product. Computers are inexpensive and compilers (Java, C#, etc.) are free. The "enough time" part has always been the major impediment to creating awesome applications. With the improvements in depth, breadth and quality of open source software components and tools, this is becoming less of an issue because major components such as databases, UI frameworks, and middleware are now readily available. Having access to high quality infrastructure components allows developers to concentrate on the value-added features of their product. Part of the explanation for the unbelievably high LOC count for everyday products (100 millions lines of code for a luxury car, 20 million for Apple's iPhone, etc) is these products run software built on an existing base of open source code such as the Linux operating system.

Average Industry Performance is Unenviable

There is strong and growing demand for ever larger more complex software systems, but our ability to deliver reliable software according to a predictable schedule and budget is not keeping up with demand and expectations.

The most often quoted study on IT project outcomes is the Chaos Report from The Standish Group. The Standish Group has been been doing biannual surveys of project performance since 1994. The 2006 version of their Chaos report showed:

[2009 report finds: 32% of all projects were successful, 44% were challenged and 24% failed. These numbers represent the highest failure rate in over a decade.]

As alarming as these numbers are, they represent an improvement from earlier years. Figure x shows biannual survey results from 1994-2006.

Figure x. Project Outcomes 1994-2006, Standish Report

*The three categories as they are defined don't account for all possibilities. According to their category definitions, a project is challenge if it is late and over budget and short on features. A project is successful if it is delivered on time, on schedule and has most of the features planned. Their research doesn't have a category for projects that under perform on just one or two of: features, budget, and schedule. In practice the distinction is not that important because most projects that under perform on schedule, budget or features under perform on all three--which is how their category of "challenged" is defined.

The improvement in performance since 1994 has come mostly from the widespread adoption of iterative methods and a shift toward smaller projects of shorter duration. Odds of success on software projects is highly correlated with project size. Large projects are much more prone to failure than smaller ones.

Here is a look at Standish data on project success by project size. As you can see from the graph, small projects (those lasting 6 months or less and costing less than $750,000) have a better than even chance of success, where as large projects costing upwards of $10,000,000 have no chance of success [Johnson, J. Turning chaos into success. Software Magazine, (1999), 30--34,39. Available at: Data also reported in Humphrey, Why Big Software Projects Fail].

Larger Software Projects are More Prone to Failure than Smaller ones

Figure x. Smaller project fair much better than larger ones

In another study, Jones reports similar results [Jones 1998, via McConnell 2006].  The data in table x show schedule performance and failure rates for projects of different sizes. The smaller the project the more likely it will complete successfully. The larger the project the more likely it will be late or canceled. The numbers in table x are slightly more encouraging than those from The Standish Group in part because data on smaller projects are included. That data from Jones also doesn't indicate which, if any, of the on time projects had cost overruns or feature shortfalls.

Table x. The larger the project the greater the likelihood of failure.

The software industry's performance on projects is nothing to be complacent with but the situation might not be as bad as it appears. The statistic that only 1/4-1/3 of all software projects end in success is widely quoted--usually as prelude to the introduction of some new tool or technique. The usual purpose is to provide justification for whatever solution follows. In this context there is a certain bias towards numbers that portray a troubled industry. The deeper the trouble the more valuable the solution. However, the statement that "only 1/4-1/3 of all software projects are successful" is inaccurate. Do you see why? Not many people do, and that can give a false impression of actual industry performance.

It's misleading to say that only 1/4-1/3 of all projects are successful. It's more accurate qualify the statistic as 1/4-1/3 of all large projects. Many who use the statistic neglect to make clear that the figure only applies to large projects.  The chances of success with small to medium-sized projects is much greater. As figure x above shows, more than half of all projects costing less than $750,000 are successful. Since there are many more smaller projects than larger ones, the raw number of projects that complete successfully is much greater than 1/4-1/3 of all projects.

Another danger with not viewing failure data with a critical eye is mistaking some outcomes as failures that might well be considered moderately successful. The results from the Standish research shows half of all projects challenged. Of these, it would be interesting to know how many of these challenged projects finished within say 120% of the predicted schedule and budget (less than a 20% cost or schedule overrun). You might not get an award for finishing a project with a 20% schedule overrun but in any industry (construction, film, etc) most customers would be content with a cost or schedule overrun that was within 20% of plan. This idea is illustrated with data from [Putnam 1997, p 7]. Out of 600 projects with planning data, 1/3 finished on time and on budget, 1/3 finished within 125% of planned schedule and budget, and the rest were off by more than 125% on schedule, budget, or both. According to these numbers, 66% of projects, large and small are successful or moderately successful. As with any statistics, these numbers are also potentially misleading. The data don't necessarily represent an unbiased industry sample. The 600 projects sample started with detailed planning data. Many projects don't start with detailed plans and projections.

There is no need to exaggerate industry performance data. There is plenty of room for improvement no matter how you present or interpret the data.

TBD: This ACM article describes another study with results that aren't as dismal as those in the Standish study: The Impact of Size and Volatility on IT Project Performance. read later

Only a 1/4-1/3 of large software projects are successful, where success is defined as delivering functional software according to an agreed upon schedule and budget. In general, for large software systems about 1/4 are delivered on time, 1/4 are cancelled, and 1/2 are delivered late, over budget or both. [McConnell 2006, p. 24]

The Standish Group has collected data on over 50,000 completed IT projects over 10 years.  The data was compiled from research surveys and personal interviews with small, medium and large companies across industry segments.

[1994 survey by IBM's Consulting Group: 55% cost more than expected, 68% overran their schedule, 88% had to be substantially redesigned. These number are quoted in S/W's Chronic Crisis, Scientific American, Wayt Gibbs, Sept. 1994, pp. 86-95.]

Standish Group survey results are summarized in [Glass 2002, Failure is looking more like success these days]

"Software project failures are common, and the biggest projects fail most often." [Why big s/w projects fail, Humphrey, Software Mgmt 7th ed, p22]

[Putnam 1997, p 7] Out of 600 projects 1/3 were on time and on budget, 1/3 were within 125%, and 1/3 were off by more than 125% on schedule, budget, or both). These were not a representative sample. There were organizations at a high enough maturity to have a measurement program in place.

The average project exceeds it schedule by 100% [Standish 2001]. Nearly 2/3rds of projects significantly overrun their cost estimates. [Lederer and Prasad 1992]

Spectacular Failures are Particularly Worrisome

In addition to poor average industry performance in general, there have also been some spectacular failures. Big failures are a cause for concern because they are more dramatic (including the loss of life) and shape opinion in a way the thousand cuts of missed schedules can't. Some of the more notable project failures include:

  1. Ariane-5 - video. From Wikipedia: "Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 37 seconds after launch because of a malfunction in the control software, which was arguably one of the most expensive computer bugs in history. A data conversion from 64-bit floating point to 16-bit signed integer value had caused a processor trap (operand error). The floating point number had a value too large to be represented by a 16-bit signed integer. Efficiency considerations had led to the disabling of the software handler (in Ada code) for this trap, although other conversions of comparable variables in the code remained protected."
  2. Denver International Airport baggage handling system - The state-of-the-art baggage-handling system was plagued by massive mechanical and software problems. Scheduled opening was delayed for almost two years at a loss of $1 million a day. Unrealistic expectations. One-of-a-kind project which made it difficult to estimate. 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners. Such a complex baggage system had never before been attempted. Contractor originally estimated it would take four years to complete. Compressed the schedule in an attempt to complete in two years. 
  3. Patriot Missile - The Patriot Missile is an air defense system consisting of a high performance radar system and surface-to-air intercept missile. During the Golf War of 1991 it failed to destroy an Iraqi Scud missile which hit a barracks in Dhahran Saudi Arabia killing 28 soldiers. A government investigation revealed that the failure to intercept was caused by a software error in the system's clock. After 100 hours of operation the system's internal clock was off by 1/3 of a second--enough to cause the missile detection system to be off by 600 meters. Fourteen days earlier the problem had been reported to the US Army and software supplier. Field operators were vaguely aware of a potential problem and were told that restarting the system could prevent the problem from occurring. The workaround solution wasn't specific about the rate of error accumulation or how often to reboot. One day after the accident, the software supplier delivered the update needed to fix the software defect.
  4. Therac-25 - A computerized radiation therapy machine. Between June 1985 and January 1987 a software defect resulted in massive overdoses in six known incidents resulting in deaths and serious injuries.

Others I could add:

  1. Federal Aviation Administration's traffic control system
  2. Virtual Case File project for the United States Federal Bureau of Investigation (FBI)

ref: Nancy Leveson and Clark Turner, An Investigation of the Therac-25 Accidents, IEEE Computer, July 1993, pp.18-41

It's only a matter of time before there is a very visible public failure due to poor quality software and development procedures before there is regulation and oversight like there is with other professions that have the potential to put the public at risk. It will happen after there is a very public visible loss and the loss is directly linked back to what is clearly perceived as software malpractice.

Why do project fail?

Software projects fail for many reasons. There are many more ways for things to go wrong than there are for things to go right.

When a project fails to meet its schedule, budget, quality or feature goals there are three possibilities. The project was performed poorly, the project was estimated poorly (and therefore doomed from the start) or some combination of both. Expectations can change people's perception of the outcome. If a project estimated to take 4 months takes 6, the results may very well be viewed as a failure. Had the same project been estimated to take 6 months, it might have very well been considered a success. The only difference between the two scenarios is the accuracy of the original estimate. One way to avoid failure to meet expectations is to always estimate high. However, in a competitive environment you won't win many contracts if you consistently overestimate.

The perceived failure on a project is a combination of performance failure and estimation failure [Kerzner, Project Management, 2006, pp. 62]:

Figure x. Perceived failure is the sum total of performance failure and estimation failure

If actual performance is less then what was otherwise achievable, the performance of the work was not as effective as it could have been. If planned performance is greater than what was achievable it represents a failure to accurately estimate performance. In the eyes of customers project failure is the sum total of performance failure and estimation failure.

It is important to understand the source of failure as it tell you were you should be focusing your improvement efforts.

Projects fail for individual reasons but when failing and successful projects are analyzed, certain patterns tend to emerge that show the same problems occurring over and over. Here are three attempts at identifying the more common causes of project failures.

Table 1 lists the most important factors related to project success from a study of approximately 12,000 projects over a 15 year period [Jones, Patterns of Software System Failure and Success, 1995]. It is interesting to note that of these 12 critical success factors, 7 are directly related and another 2 are indirectly related to project management. Research shows that good project management doesn't guarantee success but nearly all projects that are cancelled or fall significantly behind schedule are associated with poor project management.

1. Project planning
2. Project cost estimating
3. Project measurement
4. Project milestone tracking
5. Project quality control
6. Project change management
7. Effective development processes
8. Effective communications
9. Capable project managers
10. Capable technical personnel
11. Significant use of specialists
12. Substantial volume of reusable materials

Table 1. Most Important Factors in Project Success [Jones]

[Social and Technical Reasons for Software Project Failures, Jones, Crosstalk, June 2006]:

  1. Inaccurate estimating and schedule planning

  2. Incorrect and optimistic status reporting

  3. Unrealistic schedule pressure

  4. New and changing requirements during development

  5. Inadequate quality control

[Winning with Software: An Executive Strategy, Watts S. Humphrey, 2001]:

  1. Unrealistic Schedules

  2. Inappropriate Staffing

  3. Changing Requirements During Development

  4. Poor Quality Work

  5. Believing in Magic

[Another reference: Major Causes of Software Project Failures, by Lorin May, CrossTalk 7/1998]

The causes of failure are rooted in the fundamental nature of software and projects 

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures." --Frederick P. Brooks

The nature of software makes software development unlike traditional engineering and construction disciplines. The inherent/fundamental nature of software leads to engineering and project management difficulties.

Special properties of software that make the development of large software systems challenging:

With most products there are economies of scale. The per unit cost of producing most items declines as the number of items produced grows. For example, the per-unit cost of integrated circuits (ICs) is less the more you purchase. Prices are often quoted in ranges: 1-10 ($80), 11-50 ($60), 51-100 ($55).

Software is just the opposite--it has diseconomies of scale. When writing software, as program size grows--as measured by LOC or number of features--the cost per LOC or per feature increases.

The main reason is: as product size (or project size, as reflected by number of people working on the project) grows linearly, the amount of work and complexity grows exponentially.

Consider the following conceptual diagram:

[[TBD: image]


The abstract nature of software--the product of software engineering--makes software engineering different for other engineering disciplines such as chemical engineering, electrical engineering and mechanical engineering that deal with physical constraints.

Success with Software is Obtainable

[This is the flip side of why do projects fail. Here we look at the problem from the perspective of what are companies doing to succeed? What are the patterns of success. Follow with industry examples of successful companies and projects]

[TBD: Find reference to "If all 12 success factors above are present, the chances of a successful outcome exceed 95% for all but the largest projects" and insert it here. I think it is from Patterns of software system failure and success]

[List a few successful companies/projects. Primary flight control software for Space Shuttle (quality but expensive). "Five Core Metrics" page 21. Professional Software Development, McConnell, page xv.]

Despite the grim statistics and difficult challenges, many organizations have figured out how to develop reliable software according to a predictable schedule and budget.

[p22 Executive Briefing Controlling s/w development, Putnam] 664 projects completed between 1987 and 1991. Average LOC: 78,215, avg schedule: 11.56 months, avg effort: 113.98 person/months. 53 finished on time or within 1 month of planned completion date. 78% completed within 2-3 months of scheduled completion date. 62% on budget or within 5 person/months of planned effort. 73% completed within 10 person/months of planned effort. Accurate estimating (within 5-10% of actual) is possible with best-in-class organizations.

No Silver Bullet

Potential silver bullets: structured programming, CASE tools, AI, OOP, web services, Ruby, CMM, Open source, MDA,  ???.

[First, what's not the answer.] The solutions to the problems behind the dismal statistics quoted above are not simple. The problems above are not insurmountable, but there is no quick fix.

There are many proposed solutions to the problems outlined above. In fact it is standard practice to quote the dismal statistics on software project success and throw in a few of the more spectacular failures as motivation for discussing whatever tool or technique is being promoted.

[Include this section. "Those who don't know history are destined to repeat it." From the looks of things, there are a surprising number of people with a poor understanding of history. List of technologies that people overestimated their ability to have a substantial impact on the challenges of software development: structured programming (more reliable software), 4GL programming (this technology will enable users to become programmers), CASE tools (automatic programming), OOP (software created from interchangeable parts), MDA (let's appease those who say there isn't enough reuse in s/w development and reuse the idea that CASE tools can simplify programming and make it more automated by raising the abstraction level of computing). Forecasting breakthroughs that don't pan out (and admittedly, exposing forecasts of breakthroughs) is fairly routine. 

The point of this section is that the difficulties of developing software are part of the essences of software. Therefore they will always be there. If these difficulties weren't part of the essence there might be some hope of avoiding them. This observation justifies the time spent learning how to managing these complexities--they will always be there to some degree.]

Hardware capability grows at an exponential rate. What improvements can we expect from our ability to develop software? New technologies are continuously being introduced: object oriented programming, web services, more sophisticated Integrated Development Environments (IDE), etc. New techniques are continuously being introduced: agile development methods, test-first development, CMM/CMMI, etc. What improvements in productivity, quality, effectiveness can we expected from advances in technology and methodology?

In the late 1980's Fred Brooks wrote an article, No Silver Bullet: Essence and Accidents of Software Engineering, where he argued that "no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity." A decade later his prediction has largely held true and is likely to hold true for the decades to come. The reason is the essential and accidental complexities of software engineering.

Some complexities are accidental, they are not an essential or inherent aspect of the task. For example, memory management in C++ is an accidental complexity. It turns out that memory management isn't an essential complexity of programming. The complexity of memory management is eliminated through the use of newer languages (C#, Java) that support garbage collection and do memory management automatically. Some complexities are essential. You might be able to mitigate them somewhat but they will always be present. For example, the complexities associated with eliciting requirements, conceptualizing a solution and validating the resulting implementation will always be present.

Another way to categorize the software and project complexities just discussed is as essential and accidental complexities. Essential complexities deserve the most attention.

Fred Brooks (The Mythical Man-Month, 1995) divides software development tasks into two categories: essential and accidental. This categorization comes from the ancient use of the terms. Aristotle made a distinction between the essential and accidental properties of things. The essential properties of something are those properties that can't be removed. Accidental properties are those that occur by chance or a consequence of implementation. For example, an essential property of a beverage is that it is in a liquid state. An accidental property of a beverage is that it has calories. You can take the calories out of a beverage and still have a beverage. If a beverage is somehow converted from a liquid to a solid it is no longer a beverage.

What does this have to do with software development? You can classify all problems related to software development as essential or accidental. In software development essential complexities are those complexities that can't be removed. These complexities can be managed but they will always be present in the task of software development . Accidental complexities are those related to implementation. Accidental complexities aren't essential to software production. For example, the problems related to memory management are accidental complexities. The problems related to choosing implementation data structures that map to concepts in the problem domain are essential complexities.

One of the reasons it's important to recognize essential and accidental complexities is so you don't underestimate the difficulty of managing essential complexities. You shouldn't invest in a perpetual motion machine and you shouldn't expect a tool or method to solve software development problems caused by essential complexities.

Software engineering is focused on essential complexities. It's by addressing essential complexities that there is the most to gain in terms of improved product quality and ability to complete projects according to a predictable schedule and cost.

[Image that shows: |     Essential        |         Accidental     |    (circa 1960's)
                   |     Essential       |  Acc   |    (circa today)
Essential complexities don't go away easy.]

Finding the right approach: art, craft or engineering?

"I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty." - Richard Stallman

What is s/w development? Art? Craft? Engineering supported by underlying science and technology?

 Is software development an art that requires artists? A craft that require craftsman? Problem domain understood well enough that knowledge and judgment can be applied in a systematic way. That would make it an engineering discipline requiring the work of engineers. Engineers apply science and technology to develop cost-effective solutions to practical problems.

Most would agree it's all three to some degree.

Software Development Circa 1968

   Aspirations For Software Development

The distinctions are:

A better classification is probably art, craft and engineering. Engineering is supported by science. In some sense the distinction is academic. We are all interested in better ways of developing software. But better understanding the fields general characteristics will help inform improvement methods.

[tbr: McBreen, Software Craftsmanship; Also craftsmanship in general, Pye, The Nature of Art and Workmanship]

The engineering of software

What does it mean to take an engineering approach? What is the difference between science and engineering?

What does an engineering approach to s/w look like?

The engineering method

Engineering is the application of scientific and mathematical principles toward practical ends.

The IEEE defined software engineering as, "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.". Quantifiable means that an engineer wouldn't say the quality of this product is first-rate. He or she would say, the mean time to failure (MTTF) is 1 year.

The abstract nature of software makes SE different from other engineering disciplines such as chem eng, mech eng and electrical eng. Tools in other eng disciplines are grounded in physical laws of nature. No physical laws govern the behavior of software the way physical laws govern material artifacts such as buildings and bridges. There are physical laws that govern the flow of electrons in circuits. 

An engineering discipline is characterized by:

To be considered an engineering discipline software engineering needs a core body of knowledge or underlying science that can be used to solve practical problems. For example, chemical engineering has chemistry and electrical engineering has math and physics.

Engineering Discipline: Chemical Engineering Electrical Engineering Software Engineering
Underlying Science: Chemistry (Physical laws that underlie chemical engineering: conservation of mass, conservation of momentum and conservation of energy.) Math, Physics Computer Science?

To see how underlying science is used to support an engineering discipline consider the following example that shows how math and electron theory can be used to solve a practical electrical engineering problem.

In the 1989 movie Christmas Vacation Clark Griswald (Chevy Chase) covers his family's home with Christmas lights. All of the lights are plugged into a single outline that has been expanded with a huge glob of adaptors. The first time he switches the lights on they overload the power grid in his city which causes the whole city to loose electricity.

It's unlikely the whole city would loose power because of one overloaded circuit at a single house, but a very practical electrical engineering question might be "was there too many lights connected to that one outlet"? Electrical engineering is a discipline supported by the science of math and physics. We can use math formulas and physics theories to answer this question.

Two well-know math formulas describe the behavior of electricity in a circuit:

V = I * R
Voltage = Amps * Resistance


P = V * I
Power in Watts = Voltage * Amps

Assume that each string of lights has 25 7-watt bulbs on it. Each string would then consume 175 (25 * 7) watts of power. This implies each string of lights will draw 1.5 amps of current from the circuit:

175 = 120 * I
(175 watts and electrical outlines are 120 volts)
I = 1.5 amps
(One string of lights will draw 1.5 amps of current.)

Assume that Clark has 20 strands of lights plugged into one outlet. That would consume 20 * 1.5 amps or 30 amps of current. Most residential circuits can carry a maximum of 15 amps. The formal mathematics that underpins electrical engineering gives us a very specific answer to our practical problem--the circuit is clearly overloaded.

Electrical engineering is also supported by fundamental theories in physics such as electron theory. Suppose someone suggests using aluminum wire in the circuit rather than copper as a way of reducing the current draw. The theory of electrons predicts the most likely outcome. The periodic table of elements shows that that copper has 1 electron in its outermost layer and aluminum has 3 electrons in its outermost layer. Electron theory says that the number of free electrons in the outermost orbit of an element determines how much resistance that element will offer to the flow of electricity. According to the theory, aluminum with 3 electrons in the outermost orbit will offer more resistance to the flow of electrons than copper which has only 1 electron in its outermost orbit. More resistance in a circuit will reduce the amount of current drawn by the circuit. This is predicted by the formula discussed earlier: V=I*R. The theory of electrons and the mathematical formulas that model the behavior of electricity in a circuit predict that the original hypothesis is correct: using aluminum wire will reduce the current draw. There are also electrical engineering handbooks that quantify the levels of resistance each metal has. With these handbooks it's possible calculate exactly how much less current each string of lights would draw if aluminum rather than copper were used. [Theory informs practice. Clark wants to lower the current draw. Clark replaces copper wires with aluminum. Why are you replacing the copper wire with aluminum wire Clark? Electron theory predicts that it will have more resistance which implies less current draw. Software engineering: Why are you using 2 modules rather than 3? There is no equivalent physical science or underlying laws of physics for software engineering.]

The purpose of this example was to demonstrate that electrical engineering has a rich foundation of math and physics that can be drawn on to solve practical problems. (Formulas and theories) Does software engineering have a similar foundation of science it can draw on? For example, given an arbitrary subroutine:

void f(Input in, Output out) {

What fundamental formulas and theories can software engineers use to answer practical questions? For example, is there any scientific base that can be used to answer any of the following very practical questions:

1. Is it correct?
2. Can it be made any simpler and still compute the same function?
3. How complex is it? Given two routines that compute the same function which one is more complex?
4. Will it eventually terminate? (This might be a useful question to ask of the routine has ran for a long time.)

[Relationship between computer science and software engineering] Computer science does offer some fundamental theories that can be used to assist software engineers but it can't be used to answer any of the questions above. Computer science does provide some underlying theories but about the most practical problem they can answer is: they can disprove anyone who claims they have written a routine that can tell if an arbitrary program will halt (halting problem). Computer science theory can also prove the correctness of a program if it was rigorously developed using formal methods but it is only practical for small programs and requires a high skill level.

Another absolute scientific result in computer science: undecidability of equivalence. Given two programs, or more interesting for software engineering, a program and its specification, there is no algorithm (computer program) that can tell whether the two programs or the program and its specification are equivalent.

It seems like the science has more to say about what can't be done rather than what can be done or how to proceed.

[Main point: an electrical engineer has math, theory and laws of physics (ohm's law, electron theory etc.) which can be used to predict an outcome before turning on a switch. A software engineer doesn't have any physical laws to rely on but there is a large and growing body of principles and best practice when used together with a targeted metrics program can be almost as predictive as physical laws. Just like the laws of physics could have been used to predict the outcome for Clark Griswald, principles, practices and historic data can be used to predict the output of a software project before it begins.]


Software Engineering

The Institute of Electrical and Electronics Engineers defines software engineering as

"the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software." [IEEE Standard 610-1990].

In other words, software engineering is the application of engineering practices to software production.

What do you mean by "software production"?:

What do you mean by "engineering practices"?:


SE encompasses both management and programming.

Software engineering values, principles and practices





Respect for others


[Principles that are invariant across projects]

Empower workers - "details must be determined by the people doing the work" ref

Continuous improvement - 

Project objectives and system requirements must be specified in measurable testable terms. Could be a range: planned level and worst acceptable. Critical attributes [Gilb Principles of s/w eng mgmt]

Iterative and incremental development. When you deliver in early small continuous increments, problems are discovered early when it is easier and less expensive to correct them.

Metrics and measurement 

Visibility of plans and progress

Technical accountability - technical performance and decisions tied directly to business value

Early and continuous testing

Change control (or CM)

Routine design over original design


Automated unit and regression tests


Risk Management

Reviews, inspections, and walkthroughs

Pair programming

Test-Driven Development


Defect tracking

Professional Software Engineering

Software Engineering Body of Knowledge (SWBOK)

Certification and Licensure


The Market for Lemons

To understand how certification might affect the discipline of software engineering consider what effect it has had on the discipline of project management.

PMI certification grew rapidly from 19xx to 20yy. Before PMI certification it was hard to distinguish between good and bad project managers, so everyone got roughly equal pay. Certification provided a way of identifying more capable managers, so salaries are higher for those with certification.

Project managers that have PMP (Project Management Professional) certification from the PMI have an average salary that is 10% higher than those who aren't certified [reference?]. There is an even greater opportunity for software engineers to garner higher wages as a result of an effective certification program in software engineering. Why? Consider the market for lemons.

In short, when there is asymmetric information between buyer and seller, specifically when the seller has better knowledge of the quality of the goods, the buyer takes this into account and is inclined to assume an average level of quality which limits the amount of money he or she is willing to pay. The consequence is that high quality goods are driven out of the market (the most talented students go into medicine and business rather than software engineering) and the higher quality goods that remain sell at a discount--closer to the price of average quality goods. (Conversely, lower quality goods also tend to be sold at the average price which is good for less qualified practitioners but bad for their employers.)

One of the consequence of having certification for software engineers would be a mechanism for reducing the asymmetric information between buyer (employer) and seller (potential employee). If employers had some why of reliably sorting the lemons from the peaches, they would be willing to pay more for the peaches.


Code of Ethics



Why Projects Fail?

[TBD: Major causes of project failure.]

[Major factors that cause project failures] Projects get into trouble and fail for a variety of reasons.

Patterns of successful and unsuccessful projects - Broader themes generally associated with successful and unsuccessful projects.

Early Warning Signs of Potential Problems

[What makes software development so difficult? Then, how to reduce failures.]

Software projects are difficult because:


For example, it usually takes more than twice as much effort to write a 20 KLOC program than a a 10 KLOC program. (This characteristic is a consequence of the complexity of software.) The difficulty of writing a large program grows more than linearly with the size of the program. Software development is one of the few production activities that exhibits diseconomy of scale.  A 10,000 line program is typically much more than twice as complex as a 5,000 line program. Two developers working together usually accomplish less than twice what one developer working along could accomplish because of the overhead of communication and coordination. Hardware advances are making ever-larger software systems possible but software complexity and project complexity is limiting what can can be implemented in practice. [Add analogy: IC's 1-10 ($80), 11-50 ($60), 51-100 ($55). Software: 10-20KLOC ($3 LOC), 20-30KLOC ($4LOC), etc.] The complexity of N modules is not N it is NE where E is > 1. The better the design the lower the value of E.

Figure x. Growth rate in software complexity as a function of system size

Software doesn't scale well and software projects don't scale well for similar reasons. You can't expect four people working together on a project to get twice as much done as two people. With projects it's the communication and coordination between individuals that grows at a faster rate than team size. You deal with the failure of software projects to scale well in much the same way you deal with the failure of software to scale well: introduce/establish a good organizational structure that maximizes cohesion within small groups and minimizes coupling or communication paths between individuals. See figure x.

Figure x. Good team organization minimizes communication and coordination overhead

Big three: abstraction, complexity and malleability.


[Glass 2006] "The Standish report: does it really describe a software crisis?", August 2006 Communications of the ACM