This blog post originally appeared in June 2015 edition of Metropolis.
The founders of Configura have one piece of advice for designers in the digital age: Trim the fat.
“If you didn’t have so much stuff, you wouldn’t need a house,” the American comedian George Carlin once said in a now-famous sketch. “That’s all your house is … a pile of stuff with a cover on it.” Had we been in the audience, we would have given standing Os. Stuff in life—at home, in the workplace, or in an algorithm—bogs one down. It drowns. It destroys the creative spirit.
We’re Swedish—a culture known in modern times for a spare design aesthetic. But we’re also guilty of owning more clothes, cars, and collectibles than we really need. In our personal lives, we each began quests several years ago to pare down—selling the second car, for example. Saying no to stuff means making space for things that matter.
Simplicity also reigns in our work lives, because we produce software that streamlines how office furniture is specified and ordered. But software, too, has its own entropy, so you have to be equally ruthless about it.
We started out because Sune Rydqvist, Göran’s father, owned an office-furniture company called S Line. Like a lot of people in this business, he struggled to keep up with increasingly complex orders. Anyone who’s ever manufactured or sold office furniture knows the insanity of the products and their many configurable components. The number of potential combinations and related part numbers in “mass customization” is mind-boggling. It’s because too much data, or digital stuff, is attached to the products. So what happens? We specify only what we already know or we venture into uncharted territory and risk making costly, time-consuming errors.
Sune knew there had to be a better way. He turned to us—then computer-science students at Linköping University in Sweden—to design a solution. We shunned CAD-based platforms and instead created something totally new for the office-furniture world. We believed that data should be written into the software and put behind the scenes, not left out front where it creates a visual nightmare of complexity. We called our new system Parametric Graphical Configuration (PGC) and founded our company, Configura.
Creating code is akin to writing poetry. Like a good poem, the best code is only as long as it needs to be.
At its core, PGC communicates information in the manufacturing and selling process by using product symbols (instead of part numbers) to represent real products. The dealer, designer, or salesperson drags and drops these symbols into 2D and 3D drawings, creating layouts. The programming is based on algorithms instead of data. As the user drops symbols into place, the software automatically calculates all the technical details and prevents them from making mistakes. The built-in rules won’t let users put parts together that don’t belong.
PGC yielded profound results, more customers began to sign on, and we grew as a company. But after a few years, the simplicity of our solution, too, began to get bogged down. Why?
Too much code.
Those who program know what we’re talking about. Creating code is akin to writing poetry. Like a good poem, the best code is only as long as it needs to be, using the right commands, and in the right order. Code must look clean and beautiful. If it looks cluttered and ugly, it’s going to be impossible to maintain—like a hoarder’s house.
We had started out developing PGC in the programming language C, and then in C++. We pushed these languages to their limits until continuing to program in them became unsustainable. We found ourselves creating custom software for each new customer instead of designing an industry-wide solution. We needed something scalable and easy to distribute, so we decided to write our own programming language—kind of how Tolkien created Elvish. Our language is made solely for the purpose of visualization and configuration, to show how products work together.
Getting rid of stuff is a ruthless process. But what emerges is good design—pure, foundational, sustainable.
But even with this new language, we had to make our philosophy of simplicity absolutely clear to our programmers: remove the unnecessary code. In fact, don’t put it in there in the first place. Our demands ensure that programmers are focused mainly on creating code, instead of debugging data (which is really about maintaining stuff). All of us should be working this way, focusing on what’s meaningful.
But anyone who works in the digital realm—or is engaged in any kind of creative activity— knows that sometimes you are so “in the zone” that you can’t see what may be staring you in the face. That’s when you have to step away. Literally. Go outside. Throw a Frisbee. Do anything to avoid entropy, that gradual decline into disorder where your brain falls to complexity and becomes a slave to its own creation.
Letting your brain go to blank is a good thing. It makes space for new ideas, or for seeing the obvious. The path to (or back to) simplicity can be painful. Saying no is hard. Getting rid of stuff (or the old way of doing things) is, as we found out, a ruthless process. But with perseverance, what emerges is good design—pure, foundational, sustainable.