Sir C.A.R. Hoare presented an opening keynote at QCon London 2009, titled “The Science of Computing and Engineering of software”. During the keynote, he tackled two questions that keep arising in the software development community: is computing a science and is software an engineering discipline?
Hoare argued that both answers must be the same – if one of them is true so must be the other. He continued that software is engineering exactly because it exploits the results of the computing science. Likewise, computing is science exactly because its results are exploited and confirmed by software engineering.
Hoare compared the traditional roles of scientists and engineers. Scientists are interested in the long term, engineers work in fixed time scales to serve the needs of a known client for a known marketplace. The former works with scientific truths which are timeless and constant, the latter works with products that have a life span, working much more towards the short term. Scientists deal with idealism, seeking universal truths. Engineers don’t pursue ideals, they have to pursue goals of clients and customers and have to compromise between ideals and economic benefits to meet those goals. Scientists are looking for certainty, confirming their theories with many experiments and observations. Engineers can’t afford that, they deal with risk management and solving non-ideal situations. Scientists pursue perfection, engineers pursue adequacy, ensuring that whatever they do is good enough for the problem at hand and within financial and time constraints. Scientists seek generality, theories that cover wide ranges of phenomena. Engineers study specifics of particular products, services or environments or services that they are charged with implementing. Scientists look for separation of concerns, abstract rules which are true in an ideal world. Engineers look for integration, having rules applied in the real world. Scientists look for unification, defining rules which are shared with subjects and different branches of their science. Engineers are on the other hand interested in diversity, not in a grand unifying theory. Scientists insist on originality, strictly recognising work of others. Engineers often look for best practices, not originality. Scientists trying to use works of others without giving credit get excluded from their society. Engineers applying originality instead of best practices often get excluded from their society. Scientists look for formality, engineers use intuition.
Specification is nothing but a generalised test
Hoare argued that because these disciplines are so different, they can help each other so effectively. Science aims to produce truths that are universally applicable and subject them to rigorous testing and confirmation, so they require little verification in practice. The transfer of knowledge from science to engineering will help the engineering practice become more stable. According to Hoare, the fundamental limitation of scientific techniques is that it can only protect against errors which are specified with the same amount of precision as the program itself. You cannot ask a scientist to check whether a program does not contain undesirable features. The problem of deciding what is undesirable is an engineering problem, which can only be specified within a particular context. Talking about the scientific methods and verification, Hoare mentioned assertions and tests in the engineering practice as examples that can help it become more stable and produce stricter specifications. While answering a question related to TDD and using tests as specifications, Hoare said that an inverse approach is more meaningful for him, that a “specification is nothing but a generalised test”.
Hoare ended the presentation by saying that he hopes that one day software will be the most reliable component of every product which contains it and that software engineering will be the most dependable of all engineering professions. This will arise from the successful interplay of research into the science of programming and the engineering of software.
Is it engineering or a craft?
From my personal perspective, I remain unconvinced about the engineering part. Of course, I recognize the existence of computing science as a purely academic and scientific research of computational methods, techniques and rules which have ultimately led to what we now have in our computers or ways we build software. On the other hand, that has very little to do with my day to day job. And I don’t think that my day job matches the definition of engineering as well.
Engineering for me means applying stable known scientific rules in a stable known environment, and heavily relying on those rules in day to day work. Mechanical or electrical engineering are prime examples. Maybe I’m being a bit naïve, but my understanding is that in those disciplines rules of the game, techniques and technologies don’t change that often. New materials and discoveries do happen and engineers can apply them to improve products, but knowledge and application of stable more or less universal scientific rules learned through classical studies is the key to success.
In the software industry, at least in the part which I’ve experienced, rules, technologies and techniques change all the time. Knowledge taught at universities is often useless in the real world. I do have a computing science degree and have spent most of my high school days and my first year at the university learning and playing with traditional algorithms, but it has been seven or eight years since I’ve really had a chance to apply graph theory and network flows to solve a problem on a commercial project. I do use prefabricated data manipulation methods all the time, and being able to choose the correct one has to do with my knowledge of computing science, but this is really not at a higher level than applying basic mathematical knowledge such as Cartesian coordinates, so I’m as much a computing engineer as a mathematical engineer (which I’m not). My gut feel tells me that the knowledge sitting somewhere in the back of my head does help me produce better software and advise my clients better. On the other hand, I think that my experience plays a more crucial role in that. And experience is not taught in schools, it has to be learned.
I lean much more towards the idea that software production is craftsmanship, not engineering, relying on experience and implicit knowledge often working as pattern recognition rather than applying a particular scientific method.
