Criticism of software engineering
From Wikipedia, the free encyclopedia
Critics argue that many of the foundations of software engineering are inherently flawed. The following paragraphs list many criticisms and responses. Note that many of these criticisms apply to other human activities including business and education. Particular to software engineering is that there is no consensus concerning what constitutes software engineering, so critics and defenders may be using the term with different meanings.
[edit] Managing Expectations
- Criticism
- One key to successful software engineering projects is managing the customer's expectations to something that can be built and delivered. So, the field resembles marketing or sociology more than traditional engineering with its responsibilities to society at large and the perils of legal liability when they fail to protect the public interest.
- Response
- Every profession manages expectations, including all branches of engineering. Moreover, responsibility to society means meeting the expectations of the general public, which is often a stakeholder.
[edit] Poor Requirements
- Criticism
- The requirements for most SE projects are incomplete or inconsistent. Some clients have little experience writing requirements. Other clients do not know what they want, and say "I'll know it when I see it" (IKIWISI). Even experienced clients who know exactly what they want may not precisely articulate their requirements. Clients often expect much more than they write in the requirements. And, requirement documents can describe applications that have no computable or practical solutions.
- Response
- Clarifying vague requirements is one task that often forms part of a larger project. Various methodologies to clarify requirements are available, such as structured client interviews, conceptual design and simulation. Agile development methods use rapid prototyping to clarify project goals and deliver value (the most important requirements) quickly. In projects where the software to be developed is part of a larger system designed by other engineers (such as embedded systems) it sometimes possible to define the software requirements completely at the outset of the project, since the process of clarifying the requirements has already been carried out by the system-level designers. Poor requirements are a problem in many engineering disciplines, not just in software engineering[1]. Attempting to avoid all projects with poor requirements would exclude most projects.
[edit] Rising Complexity
- Criticism
- Critics argue that the complexity of requirements and user expectations have only increased. The probability of failure increases with the size, scope and complexity of the project. Technologies and practices have consistently improved over the years, but the gap between what is expected and what is delivered has not improved.
- Response
- Rising complexity actually shows the success of practitioners, because demand naturally follows supply. When clients demand more, it shows their belief that their demands will be supplied.
[edit] Ongoing Change
- Criticism
- Practitioners continually develop new technologies and practices and use them whenever possible. Critics argue that ongoing change proves that older technologies and practices were failures.
- Response
- Many view ongoing change as proof that software engineering successfully learns and grows. Traditional engineers also continually develop new technologies and practices.
[edit] Ongoing Failure
- Criticism
- Critics argue that incomplete or poorly designed systems are still too common. The early disasters in the field did not prevent subsequent disasters.
- Response
- No field that strives to do bigger and better projects has ever avoided all failures. Traditional engineers also have ongoing failures: automobiles kill 40,000 people every year in the U.S.; Three Mile Island, Chernobyl, and Bhopal Disaster harmed thousands; Space Shuttles Challenger and Columbia exploded; MTBE added to gasoline to reduce air pollution also contaminated drinking water. Although large, reliable software systems can be and have been constructed, software projects that fail during construction or in service are still too common. Ongoing failure is a problem for both traditional engineers and software engineers. Some claim that software engineering is already as predictable and reliable as many fields of engineering, such as space or biological engineering.
[edit] Failure to Pinpoint Causes
- Criticism
- Critics argue that unlike traditional engineers (who analyze failures, find precise causes, and set up guidelines to avoid them in the future), software engineers routinely fail to pinpoint causes of failure or delay precisely enough to avoid repeats in the future.
- Response
- Debugging is the activity of pinpointing the cause of failures in applications. Process improvement includes the activity of pinpointing the cause of process problems. Software engineers routinely pinpoint causes and then use the results to create better languages, databases, processes, and applications.
[edit] Nothing New
- Criticism
- Critics argue that software engineers created nothing on their own, but merely use what computer scientists already know.
- Response
- A similar argument could be made about other engineering disciplines, which are consumers of knowledge from the physical sciences and mathematics. But the primary focus of engineering (including software engineering) is the synthesis of existing knowledge into new designs to solve new problems. This inevitably involves using knowledge from other disciplines, but also requires an undertstanding of how best to use and combine that knowledge to produce useful products. In software engineering the result has been the development of optimizing compilers, make, cvs, extreme programming, scripting, and bug databases. Regardless of who creates or improves technologies and practices, software engineers (should) adopt the best ones.
[edit] Anyone Can Do SE
- Criticism
- Many bright people from other fields (engineers, scientists, business people) write spreadsheet templates or simulations, and eventually switch to writing large applications, and believe that they do software engineering. So, software engineering is not a special skill.
- Response
- Software engineering is a skill that is refined through long learning and practice. Software engineers are the ones who get the necessary education and experience, and keep up with evolving technologies, practices, and applications. This is true of every skill.
[edit] We Do Not Know What SE Is
- Criticism
- SE does not yield to the standard ways of categorization, under traditional definitions of engineering (calculus and science). This claim is often made by critics who want to impose their own definitions on everyone else.
- Response
- We know a lot about what software engineering is. Software engineering is grounded in SE technologies and practices, and applications; and in the community of SE practitioners. Of course, software engineers continue to disagree about many details.
[edit] No Software Science
- Criticism
- Civil, electrical, mechanical, and chemical engineering build on solid results from physics and chemistry. These results enable assembling complex systems in a principled and systematic way. No corresponding results are available for software: With software, we don't know how to systematically decompose complex systems into parts. Because there is no unified and agreed system for instruction on Software Engineering, it is difficult to evaluate the qualifications of those in the practice.
- Response
- Software engineering builds on solid results from computer science and information science. These results enable the building of very sophisticated software systems.
[edit] No Mathematics
- Criticism
- Many traditional engineering disciplines are based on logic and the mathematical disciplines of arithmetic, algebra, linear algebra and differential calculus, as well as the first principles of science such as Newton's laws, the laws of thermodynamics, Maxwell's equations, etc. Most of the engineering rules-of-thumb that make up traditional engineering derive from the first principles of their respective physical and mathematical foundations. Software engineering has no such first principles that all practitioners agree to, and this makes it harder to justify it as an engineering discipline as opposed to a trade or a craft.
- Response
- Software engineers use logic, proof theory, generating functions and a wide variety of discrete mathematics when creating programs.
[edit] No Theorems About People and Projects
- Criticism
- No theorems explain why one software engineer is more productive than another. No theorems explain why some software projects succeed and others fail. Without such knowledge, engineering is impossible.
- Response
- Software engineering, like other engineering disciplines, is a complex social activity. No theorems explain why one mechanical engineer is more productive than another. No theorems explain why some civil projects go over budget and fail, for example why the Big Dig in Boston went way over budget, or why two space shuttles exploded.
[edit] Meaning of Success
- Criticism
- According to a study by the Standish Group[2]. in 2000, 28 percent of software projects were complete successes (meaning they were executed on time and on budget), and 23% failed outright.
- Response
- Many engineering projects fail to live up to expectations: many bridges and buildings run over budget or schedule. Consider that 40% of all space shuttles have blown up and the rest have been out of service for years. Almost all custom housing projects run over budget and schedule. Success rates for software projects are meaningless without context.
[edit] Magic
- Criticism
- When programmers work hard and the system works, customers frequently do not appreciate how difficult the task was.
- Response
- This is true for every profession.
[edit] Software Creation is Inherently Creative
- Criticism
- Software is executable knowledge, which is discovered in a creative process, where trial and error, learning, and the ability to challenge one's assumptions are important. The true "construction" phase of software development is already automated by compilers and linkers. The difficult aspects relate to gathering requirements and designing systems. These are more like a craft than a science or engineering task. So, the potential benefit of software engineering is limited to making it easier for developers to try out ideas, to discover errors earlier, and to give them information about the state of a software system.
- Response
- Engineering design in general is "a creative process, where trial and error, learning, and the ability to challenge one's assumptions are important". Many engineers in non-software disciplines also have limited or no contact with the "construction" phase of a product or system they have designed (for example, processor designers are rarely involved in the direct fabrication of their designs). Many software engineers use agile software development to embody the creative nature of software engineering and to foster learning. The area of requirements engineering looks at how to elicit and capture what a system should do and how this knowledge can be used in software engineering activities.
[edit] Software Engineering does not Match Knowledge Acquisition
- Criticism
- Software engineering methodologies force developers to commit to the wrong decisions. The need for feedback loops in the waterfall model illustrates how the information needed to make good decisions is often discovered after the decisions are made. Decisions should not be made until developers have the information required to judge correctly, but the availability of information is always unpredictable, so a development methodology is impossible. We teach students to understand a problem completely, before starting to write a program; but this really just collapses the problem into the first step; what is the methodology used to understand the problem completely?
- Response
- This is why multiple methodologies are needed for different kinds of projects and why new and better methodologies should continue to be developed. This is also why development of a software methodology is an empirical process; good methodology results from the discovery that some design concept actually works in practice. The elements of a good methodology must be proven through use and if it works, the theory was right. These same problems are faced in any engineering design project.
[edit] No Consensus
- Criticism
- In traditional engineering there is a clear consensus how things should be built, which standards should be followed and which risks must be taken care of: If an engineer does not follow these practices and something fails he gets sued. There is no such consensus in software engineering: Everyone promotes their own methods, claiming huge benefits in productivity, usually not backed up by any scientific, unbiased evidence.
- Response
- SE is a young discipline. As consensus emerges, SE will be thought of as a mature discipline.
[edit] References
- ^ Bahill, A.T.; F.F. Dean (1997). Discovering System Requirements. Retrieved on 2006-05-03., from the abstract: "Customer dissatisfaction and cost overruns are often caused by poor requirements that are produced by people who do not understand the requirements process. ... System requirements, however, are seldom stated by the customer."
- ^ The CHAOS Report (1994). Retrieved on 2006-05-25.
