Swoopers and Bashers and Writers and Programmers

It’s funny that Bruce Eckel posted on Artima yesterday about how programming is analogous to writing.  I’ve thought that for a long time, and Eric Roberts, who developed the introductory CS curriculum at Stanford (and is just an amazing teacher in general) liked to point out to incoming freshmen that success in those classes was more closely correlated with SAT verbal test scores than with SAT math scores.  But what I’d been meaning to write about was a bit of a tangent to that:  it wasn’t about how programming is like writing, but rather about how people have wildly different writing styles, which I think everyone accepts (no one expects Dan Brown to compose a novel the same way as Salmon Rushdie or Haruki Murakami), yet people often expect that there’s One True Way to write quality software.  Method X works for them, so if it doesn’t work as well for you, it must be because you’re doing something wrong.

But the truth of the matter is that programmers program differently, just like writers write differently.  One of my favorite discussions of writing comes from Kurt Vonnegut.  In his novel Timequake, he says there are two types of writers:

Tellers of stories with ink on paper, not that they matter any more, have been either swoopers or bashers. Swoopers write a story quickly, higgledy-piggledy, crinkum-crankum, any which way. Then they go over it again painstakingly, fixing everything that is just plain awful or doesn’t work. Bashers go one sentence at a time, getting it exactly right before they go on to the next one. When they’re done they’re done.

It’s an over-generalization, but as over-generalizations go it’s a pretty brilliant one.  Personally I fall into the swooper category; in fact, I’m even more extreme in that I’ll often rewrite from whole cloth large sections or even entire essays (or e-mails, or term papers).  I’ve found that I need to get something down in some roughly-complete form simply in order to collect my thoughts, so I simply couldn’t bash out something perfect one sentence at a time no matter how much I wanted to.  When English teachers in grade school made us write outlines for an essay, I’d write my outline after I was done with the paper, because that was the only way the two would line up.

Interestingly (to me, at least), I’ve found that I’m most productive when I program the same way.  For a long time, I felt kind of bad that I didn’t enjoy doing rigorous test-driven development; it seemed like TDD was some kind of ideal of well-constructed code and if I was just a little more disciplined, I’d fully TDD everything and my code would be flawless as a result.  But in reality, that style is just sub-optimal for me.  Just like when I write, I need to sketch something out in order to really see where I’m going.  So my development methodology these days is often to start with a brutal, hacked-up end-to-end spike of a feature, write some end-to-end tests, and then start building it sideways, back-filling more targeted tests as I go and always keeping it close to some known-good state.  If I try to throw that spike away and start over with TDD, or if I don’t do that spike at all, I go slower and produce code that’s harder to read or modify later.

My point is that there is no one right way to develop; what works well for one person won’t work so well for another person.  Most developers, I think, would admit that different methodologies and techniques and tools are appropriate for different problem spaces; one-person throwaway projects are obviously a different deal from 100-person projects where the code needs to live for decades.  But even within the same problem space, people are just different, and one programming methodology or style doesn’t fit all.

As a developer, it’s your responsibility to figure out what works for you, and that requires some experimentation and often the willingness to try out something that feels horribly awkward and unfamiliar at first.  Unfortunately, it’s often hard to know if you’re giving up too early or if something really just isn’t going to work for you.  So by all means, read all you can about TDD, BDD, pair programming, rapid prototyping, getting real, modeling, or just go out there and start hacking.  Try a method out, ask people who like it, take what works and leave what doesn’t, and find the style that leads to you doing your best work.

And if you ever happen to find yourself in a position of authority, one of the worst things you can do is require everyone to try to program the same way just because it’s the way that works for you or that works for some guy in a book you read.  Give people the freedom to do their best work and, surprise surprise, they will.


5 Comments on “Swoopers and Bashers and Writers and Programmers”

  1. 2 thoughts on that:
    - i completely agree that writing code is a personal affair and hence must follow ones natural way of expressing oneself. i too find TDD (in the sense of test-first-development) far too constraining. which is also why i’ve always marveled at the countless books and people who religiously state that one absolutely must write tests first. it’s what i check into source control that matters, not what personal process i followed to produce that. (as an aside: that’s also why pair programming can sometimes be painful, because personal styles collide.)
    - the “programming as writing” metaphor breaks down (somewhat) in that most books are written by one author while most software is written by many. so these many authors must find one coherent style to write in – they must write in one voice – otherwise their “text” will be a mess. the Ubiquitous Language metaphor of DDD fits in nicely here, but obviously only covers the vocabulary, not the more general style…

    cheers,
    gerald

  2. Gus Prevas says:

    If only we were willing to make the same concession to our users, and recognize that they do their job in different ways as well…

    • Alan Keefer says:

      Fair enough . . . in our defense, we go out of our way to make the software itself configurable enough that our customers can at least fit the software to match how they want to work, rather than how we think they should work, and it’s kind of up to them how much latitude they give their own users. Of course, they’re going to take the majority of the product direction from the base product, so if by default something forces users to work a certain way, there’s a good chance it’ll be that way in production too.

      Unfortunately, I think most engineers make horrible, horrible user experience designers. Also unfortunately, most engineers tend to think they make at least adequate user experience designers. Personally I tend to think that derives from the fact that engineers usually think of the world in more black-and-white terms than, say, artists do. Compared to a novel or a painting, it’s pretty easy to determine if a piece of software is good or not. Does it accomplish its task? Is it buggy? Is it fast? Usually either something works well or it doesn’t, and it’s obvious which one it is. So a lot of engineers kind of subconsciously adopt a mental model where there’s one “right thing” or “right way” to do something, and they don’t like, say, providing two different ways to do essentially equivalent things. That’s just more code to maintain, and one of them is obviously superior, so why have the other one, right?

      • Kevin says:

        I don’t think that user experience design is necessarily as out of reach to “the usual” engineer. As long as one is willing to put aside “how I would do it” and think of it in terms of “what is David trying to accomplish” (where David is the stand-in for the average user)… and approach it with empathy, then it’s actually a natural fit for what I would call the “average logical engineer.” The reason a painting and novel is “harder” to evaluate on whether it’s good or not is because the evaluation metrics are hooked into emotional responses by the readers. I would contend that good software should do the same with its end users… and once you approach it in those terms, then as an engineer it’s possible to empathize with different sorts of people using your software. Of course, as engineers, we don’t really get a chance to go visit a site and watch how people work with our software, and from my experience I think it would go a long way towards our understanding of what we need to push for.

  3. Doug says:

    I want to give a little clapping for your last paragraph. I think that the notion that there is one best way is so easy to fall prey to, it happens nearly everywhere you go. Once someone has some success, they get into a management position and start using that to push people around to do things their way. I think it is probably just an unfortunate element of human nature, hopefully something that some awareness can help people to fight against.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 38 other followers