A sketch for a building from the 60s, modelled on computer in 2013—SEIER+SEIER

A hack is worth a thousand pictures

Could making a prototype be better than using words and pictures to communicate your idea?

Stef Lewandowski
Makeshift Thoughts
Published in
5 min readSep 3, 2013

--

Working quickly has historically been something to be discouraged.

Good art was painstaking and slow to make—Michelangelo toiled for years over his 16th Century Sistine Chapel masterpiece.

Engineering was something to be done at a considered and steady pace to ensure that what you were building would last—an idea that was only challenged in the 18th Century by the members of the Lunar Society of Birmingham, amongst others, in the industrial revolution.

The immutability of the printed word meant that writers and publishers up until the 20th Century were forced to ensure the work was as close to perfect as possible before printing it.

Rapid prototyping

The general consensus up until the 1980s seems to be that speed is a recipe for bad art. Yet this idea was flipped on its head with the beginnings of rapid prototyping. This was something very new, and it’s had a big effect on how products have been made since.

By enabling designers to produce low fidelity three-dimensional versions of what they were working on, before having it produced in a factory at great expense, it was possible to reduce the time spent in the “design, prototype, test” loop.

In 90s software development, (the sadly, rather badly named) extreme programming grew popular as a digital equivalent. In order to evaluate the complexity of a piece of work, you might do a spike—a tiny piece of code that you threw away later, that helped you understand a problem.

Now, in the 21st century, the use of the term rapid prototyping has moved from the development of physical things to also apply to the development of purely digital things.

Taking an idea and rapidly “hacking it together” as a prototype, or what many now call a hack has become a popular pastime—many of us go to hackdays and hackathons to enjoy the process with others. Yet it can be serious too—companies now use hacks to explore new digital ideas.

Communicating digital ideas

Writing has always been an excellent way of expressing an idea. When photography, print and film became mass-market in the early 20th century, the idea was born that a picture could be worth a thousand words. You might argue that this is not always the case, but watching a film or viewing a diagram certainly can communicate in a way that words cannot alone.

Yet with visual media it is all but impossible to demonstrate how something will feel to use. You can attempt to explain what Twitter is about using a video, or writing about it, but only through using it can you understand what it is for and how it works.

If you want to demonstrate or communicate how something that is of the digital world will work, react and behave, a good way to do it is to build a prototype—a hack. Perhaps the old phrase has moved on:

If a picture is worth a thousand words,
a hack is worth a thousand pictures.

A hack will not necessarily offer the emotive content of a film or a story, but it will offer a way for people to have conversations about these oddly-indescribable digital experiences.

Perhaps we’re now at the point where we can say that a hack might become something of the order of a short story, or a short film. A hack, as well as being entertaining, can be useful, or the beginning of a business or product. Through hacking we’re able to demonstrate future possibilities cheaply and easily, and tell a story in a new way.

Scratch the itch

Hacks often seem to be about itches. Little problems that are very small, clearly defined, and that can be quickly addressed with a digital scratch. To demonstrate what needs to be done, it’s sometimes easier, and much more enjoyable, to just build it than to write a document explaining it.

I’ve noticed a trend in my process around my own itches, and how we are working at Makeshift:

  • Think about your itches—Self-analyse to find things that you can work on based on your own experience and the problems you spot.
  • Scratch your itch—Do some sketching with code to see if you can do something to address your itch.
  • Pitch—Work out the simplest thing you’d do if you were to make your “scratch” work more generally for other people. Maybe get feedback from someone. At Makeshift we pitch to ourselves.
  • Hack—Do a small, focussed, possible-to-achieve, easy-to-undersand hack. A time-constraint is helpful here.
  • Strike up a conversationRelease it. Seek feedback from your peers as quickly as possible, and before you feel ready.
  • Kill or commit—Leave it at that, or if you get a good reaction, quit your job, find an investor and build it into a company. That is vanishingly rare!
  • Learn—Many people stop at the “I’m too busy to follow through” point, and forget that the hack is the message. It’s a thing you can learn from and put back into the next hack.

Putting a hack, a possible product idea, in front of people, partially unfinished, certainly untested and sometimes with a sense of abandon, has become an acceptable way to test out digital-first ideas before investing in them heavily.

Prototyping rapidity

Software developers are constantly working out new and interesting ways to improve the productivity at the “I’ve just had an idea” point. Every few days I see a “rapid prototyping framework” or a tool to “reduce the time spent doing boilerplate”.

In the past I thought that this focus on speed at the early stage was frivolous, but now I realise that we are iterating on rapidity. We are optimising for potential productivity in short periods of time—hackdays and those inspired weekends where you lock yourself away to work on something. In so doing, we’re enabling ourselves to demonstrate complex ideas in shorter and shorter spaces of time to a higher and higher fidelity.

I’ve realised that the early 80s work on rapid prototyping wasn’t just about prototyping rapidly—they were prototyping rapidity itself.They were the first steps on a general speeding-up of the ability of people to develop and communicate their ideas easily through the medium of code, design and interaction.

We’ve been iterating on rapidity ever since, and the humble hack has now become my default way to explore and communicate ideas.

If you enjoyed this, please “recommend” below—it’s a mini serendipity accelerator.With thanks to Help Me Write. There’s a story behind the image I’ve used too.

--

--