Slap Your Software in the Face

Kent William Innholt 2 min read

My old chief at a previous job taught me the notion of “analysis paralysis.” As creators with high-volume information habits, if we’re not careful, it’s easy to get stuck with too much of it. We submerge ourselves in research and data, and become unable to move forward with the creative process, because we keep looking for that one missing piece that will make the puzzle come together.

But that piece does not exist.

It’s so easy to believe that the problem space can be known fully. Yet it is not true.

Not in painting. Not in dance. Not in pop music, photography, or even Legos. And it’s particularly untrue when the material we work with is bits, and bytes, and pixels.

Software can become anything we can dream up—it’s a material with almost no friction of its own.

It doesn’t push back. It doesn’t have to deal with permanence—we can keep on changing it if we want to. It doesn’t have to deal with inherent physical properties. There’s no physical “page” that limits how large it can get. We can make an infinite amount of copies, artboards, git branches. Software as a material allows us to leave all options on the table, forever.

However, if we want a healthy creative process and ultimately want to achieve results, we can’t allow ourselves to get too mesmerized at these endless possibilities.

We have a job to do. We need to get unstuck. What we need is to just do something.

Make the page green. Or make it yellow. Pick one.

It doesn’t matter which one—not yet. We need to pick not because we care about the color, but because until we pick something, we have no resistance.

And we need resistance! We want our software to speak back to us. We need our software to be something. Only then can we react to what it is. Our software has to have an opinion.

Once it does—let’s say that its opinion is that yellow is the best choice—we can easily decide that we hate yellow and change it to pink. But until it does, creativity clogs up. In putting pressure on our software, we force it to tell us more about what we don’t want, and therefore, what we want.

And so what I’m trying to say is, tease your software. Nudge it in a place it doesn’t expect. See how it feels with a different soundtrack, or on a slow Windows XP computer, or if the user is in a hurry.

Slap it in the face! See how it responds.

So much of great software design is happy accidents. We want to believe that we can control the creative process. However, all we can do is guide it, learn to recognize our own roadblocks, and bring a full toolbox for getting our thoughts unstuck.

Take care,
/Kent William

Props to Steven Pressfield for writing one of my favorite books on this subject. If you want more updates from me, I have an RSS feed and a Twitter profile, and if you'd like to get in touch, you can reach me at kentwilliam [ at ] gmail [ dot ] com.