Skip to main content

Software as A Human Activity Between Art and Science

In preparation for my new role at VMW last year, I started to brush up on my application and development skills: I played with some little toy programs in Java and Scala and engaged with some design artifacts (yes, those amazing UML colored diagrams to reasons over problems!). I took time to write a few notes down along the way and left a few points to ponder.

With some spare hours in recent weeks, I have dug up those shaky notes and tried to mold them into a more consumable piece of information. My intention is not to delve into technicalities or technological debates. I am simply walking in the shoes of thousands of customers and organizations I have come across in my career, inviting to look beneath the surface of our pop IT culture (to paraphrase Alan Kay) and aiming to give a more nuanced view on what building software is about. The good news is that I am not inventing much or speculating over – I am going to be much more descriptive than normative so to speak. In a way I am like a reporter from the front lines. Needless to say, my own ideas and suggestions will either be obvious from the context or be clearly called out.

Given the variety of topics I recollected, I thought to boil all of them down to the following.

  • Software As A Human Activity Between Art and Science, 
  • The Nature of Software, 
  • Orders of Ignorance and Complexity, 
  • Four-dimensional Space: Design, Construct, Runtime, Artifact, 
  • Software Design – Who Killed It?, 
  • Disenchanted by Modern Software?
  • Is AI Eating the World?

A note for the hard cores out there: the software industry's evolution hasn't been a linear ascent – the latest is not necessarily the greatest.

Let’s now turn to the first one.

I will closely address the arguments about the nature of software in the next post. I now want to simply illustrate a particular angle from where software engineering manifests a peculiar “behavior” when compared to development of modern science and the arts. It is often said (but it is controversial in my opinion) that software has a dual nature: scientific and artistic. On that assumption, let’s see how it compares to arts and science. The comparison is mainly hystorical and reflects the internal and external general dynamics observable by virtually everyone.

Science vs. Arts

There is a striking contrast between the development of modern science and the arts. No one would say of a work of literature or music that it was better than an earlier work just because it was later!

A later masterpiece of say Luciano Berio is not, because of its modernity, better than Beethoven’s Violin Concerto. There just is no scale on which one could judge such things, once a certain level of expressive adequacy has been reached. It seems like in arts the past experience is continuously alive because the aim is not to demonstrate a particular truth, but to enrich our perception of the truth (or beauty). There is also another key element: in arts like music, literature, etc…as T.S. Eliot once remarked, more it’s known than our predecessors because what we know is their work.

On the other hand, the growth in science has a different trajectory. Here we are able to specify a clear aim that is our incremental understanding of the world. Thus, Copernicus’s heliocentric picture of the universe was better than Aristotle’s geocentric picture, and Einstein provided a better picture of the Newtonian gravity, etc. It’s like science can be likened to a vast graveyard of outdated theories superseded by superior ones that will at some point be in turn replaced (Note: I am adopting a Popperian-like philosophy of science). You got the drill.

What does Software stand for?

Under the umbrella term ‘Software’ I include: software engineering, programming, methodologies, user experience,  management, procurement. And I am describing what I see in the main, and a general trend. With that in mind, let’s see where Software stands in contrast with science and arts.

  • Scientists don’t have to know their history because it is a history of discarded theories, and which are regarded as giving far less true information about the world than their successors. They can be revived as historical curiosities. In Software industry a very similar attitude can be found. The tendency is to dismiss past theories, structures, frameworks, tools as relics or at least surpassed, admitting that they were useful but now we do and know better. Examples are overwhelming. Take for instance the “Microservices” article of faith. It goes like this: Monolithic applications are bad, we have evolved from that primitive way of building software, and moved to Microservices to ensure more <add as many success words as possible like scalable, decoupled, efficient, etc.>. Needless to say, here the Monolithic has been portrayed as the antagonist (inappropriately), with everything contrary to it depicted as good. This is a typical, by-the-book application of the Strawman Fallacy. A common pattern.
  • As I mentioned earlier, in the arts it is a core feature to immerse yourself with past, ancient authors and their work. Software engineers rarely know their predecessors: you mention that say Information Hiding dates back to Parnas, and actually reading On The Criteria could give you good insights about making better modular software. You won’t get much traction, nor much gratitude for those whose shoulders we are standing on.
  • Edward Yourdon popularized the concept of “Good Enough Software. It was so potent that, despite Yourdon intentions, if you dare to even hint at a critique, you are swiftly labeled as a purist. On reflection, I must say that while in Software Engineering this might be a good idea under some circumstances, I would argue that in science for example it's a bad idea tout court. In arts, it’s rare that an artist advocates a good enough piece of art, making their customers aware of his intentions (Artist: “I was anxious to sell you this drawing, I didn’t want to further delay its launch. But it’s good enough to be sold”). The point is that Software is the only artefact that can be shipped and intentionally launched to hit the market not necessarily with high quality features. The fact that in practice good-enough software is rarely good enough is a rant that I will voice when we talk about the death of software design.


In a nutshell, Software Development is a very peculiar human activity that is modulated by different forces and polarities, which are hard to reduce to one single linear driver. The mix of fads, unfettered credos, the spade of tools and apps delivered every microsecond often hide the more fundamental forces that animate the industry:

  • hard-work to acquire the right knowledge to solve real problems,
  • difficulty to channel a system vision through different layers of organizational structure,
  • represent domain knowledge in an executable way,
  • navigate through the inevitable fumes of vendor boastful claims,
  • make economic sense in choosing what to build and what to buy

The arts and science dichotomy proves to be very inadequate to make sense of this articulated human activity. I will come back to this in the next post of the series. 

***Cover: the book of Eliane Strosberg retraces in the links between art and science through over 250 illustrations and examples taken from architecture, painting, the decorative arts, chemistry; astronomy, biology or other disciplines. A straightforward style for the general public.

Comments