**Reidar Conradi**:
"Comments to Peter B. Henderson: "Mathematical Reasoning in Software
Engineering", CACM, Sept. 2003

The whole community appreciate the attention by ACM/IEEE on this
topic, and Henderson has many valid points in his paper [1]. He
initially states that: *"Software Engineering is an emerging discipline
that applies mathematical and computer science principles to the
development and maintenance of software systems, relying primarily on
the principles of discrete mathematics, especially logic".*

However, allow me to come forward with some reservations and reflections, coming from having a broader perspective on software engineering (SE) as a discipline, in contrast to computer science (CS). I have two main comments, on the importance of programming-in-the-large, and on the role of mathematics and logic.

In order to base my comments on more than subjective opinions and general arguments, I will refer to results from empirical studies among software professionals on what knowledge and skills are actually needed in their work. One of the very few studies is published by Timothy C. Lethbridge [2], and is also cited by Henderson. In this study from 1998, Lethbridge got responses from 186 software professionals in 24 countries. The respondents were asked among 75 topics, which were the most relevant for their professional work, and to what extent these topics had been covered in their formal education.

**Comment 1 on technologies for programming-in-the-large in a SE
curriculum.**

The 25 *most* SE-relevant topics in [2] can be split into: 18 CS
topics, 7 "soft" topics (management oriented), but no "hard" ones
(science, mathematics, or logic). The top 10 "under-taught" topics
include: 6 soft topics (e.g. project management), 3 “soft” CS
topics (HCI/user-interfaces, testing/verification/QA, and
configuration management), and one major CS topic (O-O concepts).

Thus, the respondents in [2] appreciate a SE curriculum centered around basic CS and programming-in-the-large topics. Although Henderson’s paper is mostly concerned with mathematics and logic in a such a curriculum, these topics were hardly among the 25 most relevant ones.

**Comment 2 on mathematics and related topics in a SE curriculum.**

The 25 *least* SE-relevant topics in [2] can similarly be split into:
3 CS topics (computer graphics, image processing, and AI), 16 hard
ones, and 6 soft ones. The top six "over-taught" topics, where a
substantial part of the contents had been forgotten since education,
are all among the 16 hard ones: chemistry, differential / integral
calculus, linear algebra and matrices, differential equations,
physics, and Laplace / Fourier transforms.

It is indeed worrying, that the mathematics being taught to software professionals (mostly calculus) has mainly been irrelevant. This is in spite of good intentions, shared by most of us, on teaching such mathematics to foster abstract modeling and general problem solving. The calculus curriculum for CS/SE must therefore be fundamentally rethought. Just teaching calculus with no applications (e.g. physics) makes little sense, and is bad pedagogic anyway.

Discrete mathematics and logic appear to be of medium relevance to
SE-professionals, i.e. neither on the top 25 or bottom 25 list of
topics. Henderson makes the following comments on the findings in
[2], that *"software engineers have not been taught to use discrete
mathematics and logic as effective tools".* I partially agree. Such
topics should also be taught by the CS/SE departments themselves, and
include semi-formal languages like UML2 and OCL – in addition to
more formal languages such as Z, Larch and Alloy mentioned by
Henderson.

Regarding the role of discrete mathematics and logic in a SE curriculum, I have two further reflections. First, to recommend logic as a prime pillar for SE, as Henderson seems to do, is ill-advised theoretically, in light of fundamental undecidability issues. So logic should play a more modest role. Second, the size and complexity of nowadays software makes large-scale formal techniques increasingly infeasible. A modern PC represents some of the most complex systems ever built by humans. Microsoft Office alone consists of 50 million program lines, but has been constructed with scant use of formal methods – like it or not.

**On principles for a SE engineering curricula**

We all agree that curricula for both CS and SE shall be founded on basic principles and theory, i.e. science-based not application-oriented. This will create a knowledge foundation for life-long learning. The more applied parts can be learned later in on-the-job training. However, we see a tendency among our own CS and SE students, that they try to avoid learning the basic and tough CS skills of e.g. programming, operating systems, or compilers. They may even get away with this by choosing "soft" roles in group work.

Lastly please note, that I am *not* against discrete mathematics,
logic, and associated formal methods. I only ask for pragmatic balance
and appropriate understanding of their applicability in SE.

Sept. 17, 2003, Reidar.Conradi@idi.ntnu.no, Norwegian University of Science and Technology, Trondheim.

**Acknowledgements:**

The author wants to thank Marvin Zelkowitz, Lionel Briand and Timothy
Lethbridge for comments on previous versions of this letter.

**References**:

[1] Peter B. Henderson: "Mathematical Reasoning in
Software Engineering Education", in CACM, Sept. 2003, pp. 45-50
(special issue on "Why CS Students need Math").

[2] Timothy C. Lethbridge: "What Knowledge is Important to a Software
Professional", IEEE Computer, May 2000, pp. 44-50.