Book a Demo
search icon
illustration

Explaining the complexity of software

3 min read

Written by: Luc Brandts

publication inner img
illustration

Why is software so buggy? Why do so many things go wrong with it? Why can’t “they” just fix it already? These are all typical questions everybody has. The honest answer is that software is really complex. But since most people see software as a black box, it’s difficult to understand. Let me try to explain using an object we all see every day.

Take a simple mechanical clock, like the one hanging on everybody’s grandparents’ wall. If it’s a basic clock, with just two arms and maybe a sound every hour, it’ll have more than 100 components. If you need a clock repaired, let alone created from scratch, hardly anyone will jump at the task. Repairing clocks requires a special skill and patience. A simple clock can probably be compared to the simplest of software programs, something like a webform entering some personal data to download some information. Certainly not something like a web payment; that’s way more complicated.

Now to something we don’t see every day. Take the most complicated watch ever created: the Vacheron Constantin Reference 57260, better known as Tivoli.

This super complicated watch has 57 so-called complications, let’s say 57 functions. In addition to telling time (obviously), it has functions for three calendars (that part alone is astonishingly complex), an alarm, power indicators, a day/night indicator, the week number, the day number, sunrise and sunset (and more…). It consists of 2,826 parts and 31 hands, think about it. It took three extremely skilled watch makers no less than eight years to design and create Tivoli. Apparently, and maybe not surprisingly, it costs several million dollars. No doubt it can truly be considered a mechanical masterpiece.

Now, let’s draw a line to software. Bear with me, it will be quite a long line. On my phone, I have a Solitaire game I sometimes play (don’t ask). Trying to count the number of its functions, I get to around 50 (start, restart, all sort of settings, moving of cards is only 6 or so), a number almost on par with Tivoli, the world’s most complex watch. Now, this is interesting. There are very few people we trust to build the Tivoli watch, as it takes extreme skills and patience. The maker of the small and simple Solitaire app built something of equivalent complexity, but because it’s software, he or she was able to build it much faster, test it, improve it, find and resolve bugs, and come to something that works.

One of the most complex automatons ever built is “The Writer” by Swiss watchmakers Pierre Jaquet-Droz and Frederic Leschot. Built in the 1770s, it has some 6,000 parts and is capable of writing small sentences up to 40 characters long. When people see it, they’re in awe and surprised by the abilities of these men, and rightfully so. They may even say that things of this complexity are no longer built, because people lack the necessary patience. I don’t think that’s true. People have built far more complicated systems, and if there were a market for mechanical automatons, we’d see many more. Today, however, we have a market of electronic automatons.

To give you a better idea, some of the most complex software in our SIG software analysis database has over 100,000 parts (with many more lines of code). This is the complexity software engineers have to deal with. Think about that next time you see a clock, a picture of the Tivoli or watch the movie Hugo (Martin Scorcese, 2011), which features the most amazing automaton. It’s fantastically complex, but nowhere near as complex as most software systems. Something to be understood by people asking for new systems and additional features. But also something that software engineers should think about. There’s a reason why making clocks is such an expert task.

Author:

Luc Brandts

Group CEO

image of author
yellow dot illustration

Let’s keep in touch

We'll keep you posted on the latest news, events, and publications.

  • This field is for validation purposes and should be left unchanged.