The science of computing and the engineering of software (Sir Tony Hoare)
In his younger days he worked on an Algol 60 compiler. It was much better
than the legacy language of the time, Fortran, of course. Fortran was 4 years
old at that time :-)
Science of computing or engineering of software: does any of those two
exist? He hopes to show that both exist and that both exist because of the
There’s a scale from science to engineering. At one end the practicing
engineer and at the other the pure scientist. With lots in between like an
engineering scientist. A practicing engineer produces working software, but
uses scientific thinking behind the scenes.
Some differences between the two, scientists and engineers:
- Science is more long-term. It is interested in eternity. You hope that
what you discover is valid for ever. Commercial engineering products are
often short-term. If you have an engineering product, it will at some time
- Scientists seek perfection and are idealists. There is no need for a
practical application. Lasers were discovered long before they were used in
consumer projects. An engineer’s task is to not be idealistic. You
need to be realistic as you have to compromise between conflicting
- A scientist is after certainty. The more proof, the more certainty. An
engineer has a lot of uncertainties and has to learn to live with them. So
an engineer is after confidence. Risk management. Confidence in the
solution. As long as the customer can be given the same confidence.
- Perfection for the scientist and adequacy for the engineer. Good
enough is good enough.
- A scientist wants to generalise. An engineer has to adapt to a
particular marketplace or situation, and so is after particularity.
- A scientist wants separation of concerns. Specialise. An engineer has
to integrate several partial solutions in one whole solution.
- Science: unification of a theory is important. An engineer is after
diversity: have knowledge of many theories and solutions and combine it.
- Science is mostly after originality. Plagiarism is The High Crime.
Engineering is after best practice. Originality means risk. The worst
thing that can happen is if a project fails because of undue risk-taking,
possibly even leading to imprisonment.
- Formality is science’s terrain. Detailed mathematical proof if
possible. Nowadays, there’s a lot of computing going on behind the scenes.
And who writes that software? Often research results end up rather in
software instead of in formal articles. An engineer relies on research
results embedded in software, mostly. In places where the software cannot
reach, the engineer relies on a finely-honed intuition. You won’t see
the word intuition in a scientific article.
- Scientists want aforementioned programs to be correct. An engineer is
after dependability in the software. Suitability to its purpose, for
Sir Tony assumes most of us present at Europython to be software engineers. So he doesn’t have to
proof that a software engineer exists.
But what about the science of computing? Well, the kinds of questions a
scientist asks are “what does a program do?”, “how does it work?”, “why does
it work?”, “how do we know?”. The same questions an animal researcher asks
- What does it do? That’s described by a specification. But then we need
to have a framework for making such specifications. Here there’s a clash
with engineers. Most software doesn’t have the kind of specifications that
would satisfy a scientist. On the other hand, it could be considered the
task of a scientist to come up with the specifications. Take aircraft for
instance as a reason for putting the task in the scientist’s hand: the first
aircraft were build without specifications. They tried things. Some
worked, some not. And it took quite a while for science to come up with a
framework for specifying the properties of an airplane so that calculations
could be done on specifications and proof of airworthiness could be
- How does it work? A start is to split a program into modules with
defined interfaces. Then you can start looking at the modules.
- Why does it work? You can answer it by the theory of program
semantics. You have the programming language as a start. Try to find out
if the program meets the specification.
- How do we know? As in all other fields: by calculation and proof. And
here we’ll have to use computers again. Code analysis tools. There is
research interest in proving whether programs actually work. Moore’s law
helps us here in lowering the cost of the research tools that look at this.
You already have program analysis tools that warn of common errors. Tony
has seen the successes of such tools in practice.
- Software will be the most reliable component of every product that contains
- Software engineering will be the most dependable of all engineering
professions. It doesn’t rust. It cannot be eaten. It doesn’t decay. If
software becomes inserviceable it is because of errors/bugs in the original
product and not because of the passing of time.
All this goodness happens because of the successful application of research
into a) the science of programming and b) the engineering of software.
Question: is there research that can help marketing come up with
specifications so that we engineers can build the software? Answer: that’s
the engineer’s job. Marketing doesn’t understand programming. Neither does
marketing understand the customers. (Loud laughing at this point).