Fumble-driven Development

First written on February 17, 2012

1 min. read

My digressive brain started to run wild while watching Bret Victor’s fascinating talk Inventing on Principle a few minutes ago.

What if we’re wrong?

What if Bret is right and the red, green, refactor isn’t a feedback loop that promotes creativity and discovery? Sure, it’s fast. It’s iterative and it gives us a suite of clearly defined assumptions to rely on in order to gauge the stability of the programs we’re building.

But what if such a science-based programming — as I like to think of it — is sacrificing an essential component of the process of building?

I recognize that as someone who begun as a designer I have a tendency to regress to that mean. The one of experimentation, trial and error. The one of repeated fumbles and smudges that with perseverance can turn into a great thing. That’s how I instinctively want to write my code even though I know that I’m not skilled or controlled enough to be trusted without the safety net provided by testing.

Another way

Or maybe the kind of programming that Bret presents through his innovative development environment is just one other way to code. A way more suited for creating visual output, animations, interfaces. Maybe that’s where the front-end development community will gravitate toward. Come to think of it, it would make a lot of sense.

It’s difficult for me to resist the appeal of a human and feedback-friendly interface. I believe the feedback loop is something too many creators neglect. A sanity check where sanity equates to reality and can take developers back down to the ground when they get lost in abstractions.

Having spent a good part of the afternoon toying with Guard and its various extensions I realize that this kind of fast and tangible output is something I have been craving for.