2.2. Software Development
When programming is done professionally,
● with the goal of developing complex software products,
● often as part of even more complex systems,
● that are maintainable over many years,
● intended for external non-CS customers and users,
● involving multidisciplinary development teams,
● under economic resource constraints,
a whole set of new problems arises. The field of Software Engineering (SE) attempts to
address these problems. It goes well beyond the basics of programming, including
● domain engineering and requirements engineering;
● modeling;
● architecture;
● evolution, maintenance;
● dealing with errors, quality control, validation & verification, reviewing & testing;
● configuration management, revision control;
● project management;
● specialized software tools for these.
However, anyone doing serious programming, even if only for personal use, can benefit from the key insights of software engineering. In fact, as a teacher you do someone
a disservice by not explaining these insights, because without them, programming can
a frustrating experience. In particular, the topics of (1) dealing with errors (in a broad
sense, including unit testing), (2) configuration management (e.g., using Git), and (3)
coding idioms, design patterns, and architecture are essential. It surprises me that the
IOI environment still does not offer standard tools for (unit) testing and configuration
management, given that the contestants must develop code that works.
Programming, Software Development, and Computer Science – The Golden Triangle 163
3. Challenges
The Asian board game go has very simple rules, yet it is a notoriously deep game. Only
recently3 have we succeeded in letting computers play above the mere beginner’s level
(ComputerGo – Wikipedia, 2019).
In chess, the world champion has been beaten by a
computer already back in 1996 (DeepBlue – Wikipedia, 2019).
Programming is like go: the basics are very simple, but it is notoriously hard to write
good programs. Michael Jackson, the British computer scientist, captures this well in his
essay “Brilliance” (Jackson, 1995), which I quote here in full.
Some years ago I spent a week giving an in-house program design
course at a manufacturing company in the mid-west of the United
States. On the Friday afternoon it was all over. The DP Manager, who
had arranged the course and was paying for it out of his budget, asked
me into his office.
‘What do you think?’ he asked. He was asking me to tell him my
impressions of his operation and his staff. ‘Pretty good,’ I said. ‘You’ve
got some good people there.’ Program design courses are hard work;
I was very tired; and staff evaluation consultancy is charged extra.
Anyway, I knew he really wanted to tell me his own thoughts.
‘What did you think of Fred?’ he asked. ‘We all think Fred is brilliant.’ ‘He’s very clever,’ I said. ‘He’s not very enthusiastic about
methods, but he knows a lot about programming.’ ‘Yes,’ said the DP
Manager. He swiveled round in his chair to face a huge flowchart
stuck to the wall: about five large sheets of line printer paper, maybe
two hundred symbols, hundreds of connecting lines. ‘Fred did that.
It’s the build-up of gross pay for our weekly payroll. No one else except Fred understands it.’ His voice dropped to a reverent hush. ‘Fred
tells me that he’s not sure he understands it himself.’
‘Terrific,’ I mumbled respectfully. I got the picture clearly. Fred as
Frankenstein, Fred the brilliant creator of the uncontrollable monster
flowchart. ‘But what about Jane?’ I said. ‘I thought Jane was very
good. She picked up the program design ideas very fast.’
‘Yes,’ said the DP Manager. ‘Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she
hasn’t really proved herself yet. We’ve given her a few problems that
we thought were going to be really tough, but when she finished it
turned out they weren’t really difficult at all. Most of them turned out
pretty simple. She hasn’t really proved herself yet – if you see what I
mean?’
I saw what he meant.
3 I wrote this sentence in 2015. In the meantime, AlphaGo convincingly beat the world champion go. And
not much later AlphaZero thrashed AlphaGo.
164 T. Verhoeff
Managers and directors (educational and industrial), administrators, politicians, they
all often still hold similar misunderstandings and misconceptions.
Fig. 1 shows the three forces that need to be balanced in a computer science course
on/using programming, both in setting the goals and choosing the means. The same
holds for a competition like the IOI. These forces pull towards the three ‘pure’ topics:
Computer science teach general concepts and insights from computing.
Personal programming teach a programming language for personal use.
Software engineering teach how to develop software beyond personal use.
I call it ‘personal programming’ here to avoid confusion with ‘professional programming’ as applied in software engineering.
Note that these three goals are overlapping but quite distinct. A course and contest
must be positioned in this force field, especially when no prior knowledge is presumed.
Paying more attention to one aspect will detract attention from other aspects. It is true
that through (personal) programming, most of Denning’s great principles of computing
can be visited, provided the trip is carefully planned. It is also the case that many lessons
from software engineering are valuable (some would even say indispensable) when doing personal programming.
Should these topics be addressed in some particular order? It seems to make little
sense to start on software engineering without a background in computer science and
programming. On the other hand, one can start to address software engineering principles and practices early on. For instance, to write program code that is readable and
understandable, through proper indentation, spacing, comments, naming, and structuring. One can write comments that document the interfaces of functions and classes. One
can think about testing, and write unit tests.
