Opinion: Software development is not art

I admit that I am a big fan of the American computer scientist Donald E. Knuth. He was born in 1938 and has been working for decades, if not years, on one of these DEM The greatest literary work of excellence in computer science, namely: “The Art of Computer Programming“. Maybe you also know him from one of the countless quotes that go back to him, for example:

Advertisement

“Be careful of errors in the above code. I just proved it correct, but I didn’t test it.

Many of his quotes are funny, profound and intelligent at the same time. One question he tackles intensely and repeatedly is: what exactly is software development? Is it an art or more of an engineering science?

Reading codes in front of a fireplace

I have already mentioned a quote from Donald E. Knuth, but there is another one that is personally the most beautiful of all for me, namely:

“When was the last time you sat in front of the fireplace and read some good code?”

Anthropic AI is outdoing itself: better image recognition, better coding

I suspect you’ve probably never done this before – in fact, you’ve probably never even thought about the fact that it can actually be done. The question arises: where we as developers work with code from morning to evening every day, where for many of us code is a language like English or French, and where we spend so much time writing code, why don’t we take the time to read it with due attention and empathetic appreciation?

And of course, it feels very strange to do so at first. But, if you studied computer science, you will remember that during your studies there was always talk about looking for elegant and beautiful solutions. And we know this from other scientific subjects like mathematics: there, too, there is always talk of beautiful and elegant proofs. So if there is any beauty inherent in algorithms or proofs, why don’t we consciously take the time to understand them and, if necessary, praise them accordingly if they are particularly successful?

Code as art?

You might say that this is too academic and far-fetched for you, but think about the term “hacker” for a moment. Today we use it to describe someone who breaks into computers with malicious intentions and steals or destroys data. Today a hacker is a vandal, a criminal. But this wasn’t always the case. When the term emerged in the 1980s and early 1990s, it referred to someone who could solve complex and complicated problems in intelligent, clever, and ingenious ways and come up with elegant and beautiful solutions in code. In other words, there was a time when we were intimidated by code artists.

And if you look again at the title of Knuth’s monumental work, you will see: it is called “The Art It’s about “computer programming”, not just “computer programming” or something similar. It’s about “art”, ie. Art of programming. And Knuth really wants it to be understood this way, since he has on various occasions compared programming to composing music or writing poetry and said that these are all aesthetic experiences in which beauty is created. Personally, I find it remarkable to think about writing code from this perspective.

Software development as an engineering science

If we compare this with what happens in everyday life and the work of most developers, it is usually very far from art. Among other things, you notice this very quickly in the words we surround ourselves with: it is about software.EngineeringIt’s all about the softwarefactoryis computer science considered there Engineering Science What is seen is predictable, planned and fatalistic. In other words, it is so far from an artistically creative approach that it is astonishing (or, depending on your point of view, horrifying).

Then the question automatically arises: who is right? What exactly is computer science? What is the essence and core of all this?

A look at the industry shows where the journey is headed: Tests? They’re often skipped, cost money unnecessarily and aren’t that important. You know: you got this Cheaper software through fewer trials. Documentation? Nobody needs it, it only costs money and, above all, time. Clean code? Well, if we really have to, we can probably do a refactoring sprint once a week, but after that you have to write new features again, because after all, the customer doesn’t pay for clean code. The customer generally doesn’t pay for code, it doesn’t matter to him. In fact, the customer is paying us to solve a problem pragmatically and efficiently. And the fact that we do it with code and not with a screwdriver is a secondary aspect.

70,000 lines of PHP code

The amazing thing about all this is that it works. Several years ago I met someone in a large corporation who was working alone on analysis software for the board. His code (and this story is actually true and not a joke) consisted of 70,000 lines of PHP code in a single (!) file. There was not a single automated test, automated deployment, CI/CD pipeline or anything like that. He did not even deal with version management, but edited a single PHP file directly on the production server using VI.

And he actually thought this was a good thing, because when he finally saved this one file after hours of editing, the application immediately deployed again. The worst part was that in the team he was a part of, he was the one who wrote the most stable and reliable software ever. The icing on the cake to all this: the PHP script was accessible via multiple symlinks, and depending on how it was called, it behaved differently. The board loved him, but whenever he went on vacation or got sick, everyone else on the team cursed him and trembled.

Where does the discrepancy come from?

As an external consultant, which I was working for this team at the time, you are there with all the best practices you want to tell for good code quality, like unit testing, integration testing, static code analysis, version management, containerization, continuous integration, continuous deployment, etc., and you are told that it’s all fine, but everything works perfectly and changing anything in the existing process would only cause disturbance.

And as much as this scene bothers me from one point of view, on the other hand I have to admit: yes, they solved the underlying problem with their 70,000 lines of PHP code on the production server and delivered to the board exactly what they wanted reliably. The time numbers were delivered. That’s what was important (at least from a certain point of view). Yet, when I tell this story, I’ve never met anyone (be they a developer or a manager) who said: “Wow, great! From now on we’ll do it this way!”

Because somehow in the end everyone wants more reliability in terms of quality etc., especially since this is what is said at every conference, in every meeting, in every blog or on Youtube, including by people like me. But I also have to admit that the practicality and development aimed at solving the problem cannot be dismissed outright. It works. But why does nobody recommend it? Where does this discrepancy come from?

Art vs. Business

Ultimately, I believe it is because two opposing perspectives collide: this is where art meets business. And finally, computer science is both at the same time; computer science is a duality; we constantly experience the effects of this duality in everyday life, because every day there are some points of friction where these two worlds and these two perspectives come into conflict with each other. It starts when you have to provide an effort estimate. Personally, I always think to myself: “How long will I know how long it will take me to do XY?”

After all, it’s called softwareDevelopment No more softwareProductionand I can accurately estimate the effort if I’ve already accomplished the task in the same way or at least something similar, but then I can just copy the code from the previous implementation and don’t have to develop it again. And it’s not just me, it’s the same for many developers, which is why I personally think that estimating effort is relatively pointless.

Ultimately, asking a developer about effort estimation is like asking Picasso if he can estimate how long it would take him to paint a picture of a crocodile, after all it was just a line of his dachshund and could last at most five minutes. But the truth is: art cannot be appreciated. Conversely, I can also understand that in business you want to be able to plan and see the result: when I’m building a house, I don’t want to hear that the rough plaster is not finished yet because “the maestro’s hand hasn’t been perfect for a week”. Find the momentum and the right motivation to wield the trowel.

need a scale

However, these two approaches are also two extremes, and as always when there are two extremes, there is also something between the poles. That is, after all, we are talking about a scale in the whole matter. At one end is pure art, which sees software and code as an end in itself, so to say “l’art pour l’art”. At the other end of the scale is purely practical business, where it is about solving problems as efficiently and cost-effectively as possible and not being artificial (attention, pun intended). Code and software are purely a means to an end.

I suspect the truth lies somewhere in the middle, because art without application does not emerge from its ivory tower. But art without application has no soul. And the most important question is: where do you stand on this scale?

I believe that if more developers thought about this question and defined an approach for themselves, and if companies did the same, and then talked about the corresponding value system, development would go much better and more smoothly, because there would be fewer conflicts and misunderstandings about the nature of development.

And then software development can really be exactly that: not art.

(RME)