The science of computing and the engineering of software (Sir Tony Hoare)¶

Tags: europython2009, europython

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 other.

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 get outdated.
• 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 interests.
• 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 instance.

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 for instance.

• 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 delivered.
• 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.

One day...

• Software will be the most reliable component of every product that contains it.
• 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).