Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Monday, August 11, 2008

Art, Craft or Science?

Is software design an art, a craft or a science? This question has been the starting point for many entertaining discussions. And many different opinions and answers exist.

So what is my take on this?

To build a software system requires engineers to come up with a mapping that takes the problem and maps it to a concrete solution. Requirements describe the problem and the desired properties of the solution. Unfortunately, the mapping typically is not unique in that there might be many solutions solving the same problem. With other words, architects and developers face a lot of freedom. The bad thing about freedom is that it always forces architects to take decisions. In other words, to architect is to decide.

Of course, we appreciate if we can immediately find an appropriate solution for all problems, just following a divide-and-conquer strategy of software development.  But this never happens in practice.

Two problems come to my mind in this context:

  • Sometimes we encounter problems for which we neither know a solution nor can find a solution elsewhere (finding a solution means either knowing a direct solution or being able to map the actual problem to another problem for which you already know a solution - for example, if we are able to map our algorithmic problem to a sorting problem.)
  • In contrast to mathematics, the problem itself is a moving target in software engineering. Pantha rhei.

The first issue implies that you may not find a pattern or some other kind of best practice for your concrete problem context. Instead, you need some intuition. Hopefully, you recognize that the problem at least resembles another kind of problem for which you already have a vague solution idea so that this can serve as a good starting point. By the way, this is the reason why it turns out to be so hard to build a general problem solver for software engineering. Freedom is very hard to deal with by a general problem solver.

The second issue, coping with change, requires some sort of agility. In contrast to logic, our axioms keep changing while we are applying the calculus. The only way to deal with change is to embrace change everywhere, in the process, in the tool chain, in designing, in testing, in refactoring, in programming, in communicating.

What makes software design so hard sometimes is when both problems appear in parallel.

When people ask whether software engineering is a craft, a science, or an art, the answer should be obvious now. It is a science as we try hard to follow formal approaches where feasible. It is a craft because solving problems often requires experience and best practices. And it is an art as software engineering leaves enough freedom for intuitive and even artistic solutions.

I guess this is what makes our job so interesting. 


  • The problem with software is that there are no rules.

    In reference to another post by "Anonymous" (in German), it is harder to make a "science" out of software than it was for physics, chemistry, or biology, because those sciences were already "invented" for us. We simply studied and learned them (and wrote about them) based on mathematics and experimentation.

    Not possible with software! Every time you sit at your computer, you have the ability to create your own worlds, your own universe, with whatever rules you want.

    Which, of course, is what we must do. It is just hard to create the right rules (the right physics) for our "computer" universe, as I imagine it must have been for whomever (or whatever) created the one in which we live.

    By Blogger chris.bahns, at 4:00 AM  

Post a Comment

<< Home