Frankensteining

29 October 2022

I hope you’re enjoying spooky season. With Halloween around the corner, I thought I’d spill some ink about a season classic: Frankenstein.

Kitbashing

Adam Savage, the former host of MythBusters and famous maker, started his career in set-making. To craft realistic-looking props for films like Star Wars: The Phantom Menace, he took hobby modeling kits (for trains, cars, airplanes, etc.) and combined them to build new spacecraft. Many special effects artists use “kitbashing” for their first versions because reusing existing kits is cheaper and faster than building from scratch.

Kitbashing removes unnecessary complexity to help makers make. A similar process happens in software too. New apps are “hacked” together as developers copy & paste components, leverage assets from open-source projects, and cut corners to launch quickly.

In a way, Victor Frankenstein followed a similar kitbashing approach when creating his monster. Rather than grow new body parts (shockingly, organic 3D printing wasn’t available in 1800s Germany), Victor robbed graves and stitched together his harvest to make a creature.

From Ugly Duckling to Clunky Monster

Version one is always ugly. A hacky app built by a pizza-powered, sleep-deprived developer won’t be pretty, but it has an earnestness that makes it almost cute, like an ugly duckling.

An ugly first version is inevitable when innovating—be it an app or a movie prop.

Because a kitbashed ugly duckling quickly solves a problem, people like it. They start to use it, grow attached to it, and ask for more.

For an app, users request new features, and the well-meaning maker adds them. Even though the components may not elegantly integrate with the rest of the product, the users are happy, and the ugly duckling remains effective.

But then the maker bolts on another feature, like Frankenstein stitching on a stolen limb, and things change. The experience grows cumbersome, the performance degrades, and the “it factor” fades.

“Frankensteining” comes from a place of earnestness and invention, but after too many iterations, the cute early version is no more. All that remains is a clunky mess.

### An Enlightened Refactor

Our once ugly duckling has become a monster rampaging through town, terrifying users. The bolted-on components become more cumbersome than valuable, so we create new problems.

When newcomers join a project like this—they may gawk at the monster’s hideousness. They point fingers at it, scream, and cast shame upon its previous creators. How could someone spawn something so vile?!

As works of fiction like Frankenstein teach us, we ought to approach these cases with curiosity. It’s unfair to cast judgment upon a monster when we don’t understand the history that created it.

Frankenstein’s monster is the byproduct of innovation. Successive iterations generated learnings that led us to the current state. Don’t shame the monster—embrace it and thank it for being part of the creative process.

But then, bid it farewell.

If our creation will live on, it needs a refactor. Some say refactors are an antipattern—an accumulation of too much tech or design debt—but I see refactors as a product’s natural evolution. We couldn’t have known the future.

With the knowledge gathered from bolted-on Frankenstein parts, we can intelligently design a refined version two.

### TL;DR

“Kitbash” your way to an ugly first version
When you “bolt-on” new features, you’re “Frankensteining” a monster
If your creation becomes too hideous, refactor