Passionate about engineering enterprise grade IT systems and the development teams doing that
Although a lot of subjects in the field of software development reached a common understanding, one continues to be a matter of controversy: software development, is it craft or science?
Craft or science… you might wonder why anyone would care. Well, probably many people don’t care, but, as we will discuss shortly, your opinion on this has consequences on how you approach software. Let’s first look at some quotes of people who do care.
Already in the mid 70’s Donald Knuth felt the need to dedicate an article to this discussion, after publishing a series of books titled The Art of Computer Programming (1). He concluded the following:
We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. (2)
That seems to be a clear statement, but the same article mentions the quest ongoing for several years already to make programming a discipline of science.
Another article, roughly twenty years later, shows that this goal was still not reached:
Today’s software developer is somewhere between a craftsman and an engineer (3)
It seems these authors desire software development to be a science, but keep finding the software engineer is not there yet (3). Also in 2003, three decades after Knuth’s conclusion, an article of Pyritz
...argues in favor of craftsmanship without ignoring best practices. (4)
The existence of Software Craftsmanship conferences (5) in recent years and still more articles appearing on this debate (6) show the discussion still did not come to a conclusion.
Considering this limited review of literature, we see software programming requires craftsmanship, at least according to some people.
But what if software development would be a science? Science has properties that are very desirable for software development. First of all, results from science are reproducible (7), under the same circumstances we expect the same outcome. Furthermore, science has high quality standards on documentation and publishing, giving insight in validity of the results. Additionally, the scientific method is a widely accepted methodology (8), helping practitioners to cooperate and perform. Abstraction methods like generalization and induction allow reuse of existing scientific results, applying it to a broader scope or different field than it was originally created for. Reproducibility, documentation, validation, methodology and reuse are desirable and important aspects of software development as well.
The desirable properties of science most likely explain the ambition of software development to classify as a science. Despite this comprehensible ambition, our limited review of literature above shows the current state of software development methodologies does not qualify as such. Although the properties of science are quite natural for a computer system, that does not make them properties of software development as well. This, because software development comprehends not only the actual computing but is also dependent on the process of requirements engineering, organizational changes, implementation plans, business cases and adoption of the new system, which all involve a lot of human factors. Despite the fact that humans are considered the most rational beings on the planet, they are so in a very limited, biased, unenlightened and emotional way (9). These human factors impair the properties of science for software development, making us
...probably feel more comfortable describing the software development process as an "art" or a "craft", possibly bordering on "witchcraft." (6)
So we have concluded software development is not a science but a craft. In line with that, would that automatically make it a form of art? To answer that question we will have to examine whether software development complies to the criteria of art. However, defining art appears to be rather complicated. Despite thousands of years of debating, mankind still did not manage to come to a conclusion on the definition of art. It is even argued whether such a definition is possible at all (10). Nevertheless, the different ideas on what makes art art give us sufficient guidance to say something about the artistic value of software.
Attempts to define art can be grouped in several categories (10), which we will now shortly discuss. The category of institutional definitions define art based on the work of art being produced in a context of art. This context is referred to as the artworld. With this type of definition the judgement of the people belonging to the artworld determine what is considered a work of art.
Another category is based on the work of art having an art-historical relation to some earlier artwork, hence this category is named historical definitions. Historical definitions often have difficulties in qualifying radically different new types of art, as no relation to former artworks exists for these types.
Next to these two conventionalist types of definitions, traditional definitions exist as well. These focus more on the functions or intended functions of the work. Most of the traditional definitions come down to the requirement that a work of art has some aesthetic properties. Meaning it should have something to do with beauty or the perception of beauty.
This brief and high-level overview of definitions of art shows how complicated it is to define art. However, it does provide several aspects to take into account when determining whether something is a work of art.
Relating the aspects derived from definitions of art to software development, we find interesting similarities. First, we see a software development community exists. This community has its own views, culture and principles and could be considered an artworld. In this artworld of software development some programs are acceptable and others are not, which is corresponding to an institutional definition of art. But also traditional definitions of art, requiring aesthetic properties, allow defining software as art, provided there is some beauty or perception of beauty in the software code. The large amount of hits when searching the Internet for 'beautiful code' demonstrates beauty is definitely considered a property of software. Therefore, we conclude that beautiful software code is a form of art.
A lot of software products end up unused due to not building the right thing or not building the thing right (11). For these software products developers have been working hard, spending precious time and energy on building the product, meeting deadlines and doing overtime to finish this software product, which in the end will never be used.
Luckily, we now know it still had a purpose as they produced entities of art, if only aesthetics were taken into account. So whatever failure-prone project you are upto, just make sure you write beautiful code!
Lead image by cottonbro@Pexels
Create your free account to unlock your custom reading experience.