Is writing software more like Building a Bridge or Making a Painting?

Several weeks ago, my friend and colleague Dan Calinescu asked and answered (on LinkedIn) this question:

Is software development more like building a bridge or more like painting a painting?

Dan had asked me this question a few years ago, on the day we met, in the first meeting we had together. I had arrived in Romania (from Seattle) for the first time, to meet with the team (which included Dan) that I had just started to manage. In his post, Dan says that most people he asks (primarily in software development) says it’s more like building a bridge. Dan argues (as he did that day in Romania) that it’s the latter, stating that

Software development is more like painting than it is like building a bridge. A lot more like painting. A lot as in 80%-90%.

He’s wrong. Although Dan makes many valid points in his article, he’s wrong on the basic premise. He’s right that creative people can make excellent software developers. He’s also correct that it’s valuable to have developers who challenge requirements that don’t accurately describe the problem to solve but, instead, define a solution.

Here’s the truth:

Software must do something. That is it’s primary purpose – to serve a need; to meet a requirement.

Similarly, a bridge serves a purpose – to cross a body or water (or some other gap). It has a function and, more than anything, it has to fulfill that function successfully. It might have multiple purposes (like the Tower Bridge in London, now serving car traffic and also housing a museum). But, more than anything, it must do what it is intended to do.


Once that purpose is met, other factors are important and must be considered. Bridges are seen by lots of people, so it’s valuable for them to be visually appealing. They represent (and can become an iconic symbol of) the communities where they are built, so it can be important for them to be creative. San Francisco’s Golden Gate Bridge is a well-known example.


Like a bridge, once a software product meets its requirements, it must also have artistic considerations. Ugly software is worse than beautiful software. In fact, ugly software can make it fail to fulfill its purpose. Users are unable to use software if they can’t locate its features. Further, a beautiful, elegant user interface enhances a software product (or website) (or mobile app) and makes it “better”, even if its only virtue is its appearance.

A painting, unlike a bridge or a software offering, has no primary function other than its appearance. It may be intended make a political statement or engender an emotional reaction or portray an individual or a scene. However, it doesn’t (by itself) do anything.

And that’s the difference. Like a bridge and unlike a work of art, software must do something.

What do you think?

I first wrote this post to be published on LinkedIn – you can find that here.
Tower Bridge image courtesy of Vichaya Kiatying-Angsulee at
Golden Gate Bridge image courtesy of Arvind Balaraman at
This entry was posted in General, Management. Bookmark the permalink.