Movements are an excuse to think

Jason Gormon wrote a post against software movements:

The problem I perceive is that this kernel of useful insight tends to become enshrouded in a shitload of meaningless gobbledygook, old wives tales and sales-speak, so that the majority of people jumping on to the bandwagon as the movement gains momentum often miss the underlying point completely (often referred to as “cargo cults”).

I think this is generally accurate.  But is it actually bad?

The thing about movements is that it gives people an excuse to think about the software they’re working on.  Pair programming is “get two people into a room thinking about the feature as it’s being written”.  Code reviews are “get two people into a room thinking about the feature after it’s written.”  TDD is “think about how the feature will work before you write it.”  Design patterns are “think about how different programs you’ve written in the past are similar.”  Data-driven architecture is “think about how the data moves through the different stages in your program.”  Readme-driven development is “think about how you will explain this program to others.”

I think if you focus on the differences between the movements, it does look absurd.  Why is model-driven any better than UI-driven?  Why is TDD any better than RDD?  Sometimes it’s better, sometimes it’s not, most of the time it’s irrelevant.  Sure, intra-movement arguments are usually stupid.

But I think you can also look at the similarities of movements–that they all emphasize thinking about the code we’re writing.

If you watch a new driver learn to drive, they have to focus.  They have to think about it.  Making a left turn is a task that requires concentration.  Experienced drivers can go from A to B without expending a single conscious thought about it.  That is basically unimaginable to the new driver.

Most code is boilerplate.  Once you’ve spent a year learning five ways to iterate over an array, you will never consciously think about it again.  Most code just does not require advanced techniques and complex algorithms.  How many times in your professional career have you implemented so much as your own sort?  I’m working on a particularly challenging project that involves new research, and the “hard code” constitutes less than half of the prototype, and will constitute less than 10% of the final application, and this is one of the hardest software projects I’ve ever seen.  It’s really easy to go through life on autopilot, even working on extremely technical applications.  And for the people who really are experts in, say, statistical graph algorithm analysis, they operate on autopilot too–they have just as much experience with statistical graph whatnots as ordinary programmers do with for loops.

What movements do is: they make boring things fresh.  For the first time ever, we’re thinking about a for loop again.  In a code review:  is it a good idea that Jim put a for loop here?  In preparation for the code review:  What will Bill think of putting a for loop here?  In TDD:  should I put the body of the for loop into a different function so that it’s more easily testable?  In RDD: do I need to document this for loop?  As far as I’m concerned, the merits of the movements in theory pale in comparison to the usefulness of this kind of conscious analysis in practice.

Yeah, if you’re focusing on movement X vs movement Y, in the abstract, it’s all stupid, because in most dimensions X is not strictly greater than Y.  But I can’t count the number of times that movement X, for arbitrary X, forced me to think about my code long enough to discover a new way to solve the problem that saved me a ton of time, or that caught a bug, or that just plain moved the code into my conscious brain-space in a way that made me faster at writing it.

---

Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.

Like this post? Contribute to the coffee fund so I can write more like it.