Dr. Dobb's | Software Engineering ≠ Computer Science | Jun...

Highlighted by ignitesrini

oftware engineering has an essential human component. Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science -- perhaps the cyclomatic complexity of the software's control graph. But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code. The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software.

The same is true for safety. Researchers have used some formal methods to learn about a software system's impact on people's health and property. But no discussion of software safety is complete without appeal to the human component of the system under examination. Likewise for requirements engineering. We can devise all sorts of interview techniques to elicit accurate requirements from software stakeholders, and we can create various systems of notation to write down what we learn. But no amount of research in this area will change the fact that requirement gathering often involves talking to or observing people. Sometimes these people tell us the right information, and sometimes they don't. Sometimes people lie, perhaps for good reasons. Sometimes people are honestly trying to convey correct information but are unable to do so.

This observation leads to Connell's Thesis:

Software engineering will never be a rigorous discipline with proven results, because it involves human activity.

This is an extra-mathematical statement, about the limits of formal systems. I offer no proof for the statement, and no proof that there is no proof. But the fact remains that the central questions of software engineering are human concerns

Highlighted by ignitesrini

Software engineering has an essential human component. Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science -- perhaps the cyclomatic complexity of the software's control graph. But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code. The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software.

Highlighted by hyamshart

Connell's Thesis:

Software engineering will never be a rigorous discipline with proven results, because it involves human activity.

Highlighted by juhariis

What should this software do? (requirements, usability, safety)

What should the software look like inside, so it is easy to fix and modify? (architecture, design, scalability, portability, extensibility)

How long will it take to create? (estimation)

How should we build it? (coding, testing, measurement, configuration)

How should we organize the team to work efficiently? (management, process, documentation)

Highlighted by hyamshart

But the fact remains that the central questions of software engineering are human concerns:

• What should this software do? (requirements, usability, safety)
• What should the software look like inside, so it is easy to fix and modify? (architecture, design, scalability, portability, extensibility)
• How long will it take to create? (estimation)
• How should we build it? (coding, testing, measurement, configuration)
• How should we organize the team to work efficiently? (management, process, documentation)

All of these problems revolve around people.

Highlighted by juhariis

Tried-and-true methods that work for one team of programmers do not work for other teams

Highlighted by hyamshart

Exhaustive analysis of past programming projects may not produce a good estimation for the next

Highlighted by hyamshart

As an example, David Parnas wrote a wonderful paper in 1972, On The Criteria To Be Used in Decomposing Systems into Modules. The paper describes a simple experiment Parnas performed about alternative software design strategies, one utilizing information hiding, and the other with global data visibility. He then drew some conclusions and made recommendations based on this small experiment. Nothing in the paper is proven, and Parnas does not claim that anyone following his recommendations is guaranteed to get similar results. But the paper contains wise counsel and has been highly influential in the popularity of object-oriented language design.

Another example is the vast body of work known as CMMI from the Software Engineering Institute at Carnegie Mellon. CMMI began as a software process model and has now grown to encompass other kinds of projects as well. CMMI is about 1000 pages long -- not counting primers, interpretations, and training materials -- and represents more than 1000 person-years of work. It is used by many large organizations and has been credited with significant improvement in their software process and products. But CMMI contains not a single iron-clad proven result. It is really just a set of (highly developed) suggestions for how to organize a software project, based on methods that have worked for other organizations on past projects. In fact, the SEI states that CMMI is not even a process, but rather a meta-process, with details to be filled in by each organization.

Highlighted by ignitesrini

We should stop trying to prove fundamental results in software engineering and accept that the significant advances in this domain will be general guidelines.

Highlighted by hyamshart

Other areas of research in this spirit include design patterns, architectural styles, refactoring based on bad smells, agile development, and data visualization. In these disciplines, parts of the work may include proven results, but the overall aims are systems that foundationally include a human component. To be clear: Core computer science topics (below the bright line) are vital tools to any software engineer. A background in algorithms is important when designing high-performance application software. Queuing theory helps with the design of operating system kernels. Cleanroom engineering contains some methods useful in some situations. Statistical history can be helpful when planning similar projects with a similar team of people. But formalism is just a necessary, not sufficient, condition for good software engineering. To illustrate this point, consider the fields of structural engineering and physical architecture (houses and buildings).

Highlighted by ignitesrini

ood software engineering also includes creativity, vision, multi-disciplinary thinking, and humanity. This observation frees software engineering researchers to spend time on what does succeed -- building up a body of collected wisdom for future practitioners. We should not try to make software engineering into an extension of mathematically-based computer science. It won't work, and can distract us from useful advances waiting to be discovered.

Highlighted by ignitesrini

In the same way, classical computer science is helpful to software engineering, but will never be the whole story. Good software engineering also includes creativity, vision, multi-disciplinary thinking, and humanity. This observation frees software engineering researchers to spend time on what does succeed -- building up a body of collected wisdom for future practitioners. We should not try to make software engineering into an extension of mathematically-based computer science. It won't work, and can distract us from useful advances waiting to be discovered.

Highlighted by hyamshart