This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Visit the Product Blog for more information on our products.

For me, the solution to this infinite feedback loop is to use paper and draw something. Draw the interface you want. Then write code to make it happen.

The first few times you do this, you will in fact have problems with your UI that only get noticed when you try to write the code. You will have to revise some small part of your UI until it reflects reality. This is far preferable to doing lots of fruitless thought experiments.

But doing this exercise just a few times will give you a very firm grasp on how to design user interfaces. The practice is worthwhile, and you end up with the skill, the ability, to see the code problems in the interface design as you draw the interface and not afterward, leading to both better interfaces and better code.

“It’s ironic that, even after nearly 4 years of drinking the Getting Real message almost every day, I’d get stuck in such a trap, because the solution really is to just stop pretending and make something.”

I don’t know if it’s ironic, so much as human. I think there’s a bit of a barrier we hit whenever we’re presented with a new task. I often find myself in the situation where I need to do something and I know that the very act of getting started, putting some code down or ink on the page will break that barrier, but still I often avoid it. Thinking deep about stuff is hard. We do our best work that way, but I think it’s natural to avoid doing it.

“I had wasted almost two days worrying about a non-issue.”

Does your employer know about this? Seriously, though, good insight.

“loop after loop, ad nauseam”

I was battling this cycle just a few days ago. It’s amazing how difficult a task can be until you dive in and let it absorb you. Just take the plunge. :)

Great story, and again, I can’t credit you enough for putting your self-criticisms on display for all to see.

Quick question though, just out of curiosity—is it built yet? Did you re-encounter any problems you anticipated or similar to those you had anticipated?

That’s exactly why we start all of our designs on paper. We’ve created these 8 up sketch boards that have 8 small screens or tiles on each 8 1/2×11 piece of paper. I just grab a pen and start drawing on paper first. It’s fast, cheap, and easy to correct, or strike through and move to another tile.

Once I get the design 70-80% figured out, I move into our XHTML /CSS/AJAX prototyping framework and start building it. The rest is figured out along the way.

But it’s really important to just plan a little and prototype the rest.

I’ve done this as well. Thanks for posting this lesson Jamis. I think this will help me recognize the issue earlier next time.

I keep a big stack of paper on my desk with my trusty colored pencils all within easy grasp.

Every problem has a quick solution when you start sketching it. Sometimes just drawing a box and starting without plan, but starting, helps me make up my mind.

You’re right Jamis…doing is way better than thinking about doing. Smart people, like the ones reading this blog, will see all the layers of a problem and get tripped up. Actually solving the problem a lot of times is much simpler!

Great insight. I catch myself doing this as well. But how is pretending different than laziness or mental inertia? When a job perceived as simple (“the change itself pretty straightforward”) goes wrong we usually feel stingy about investing more time on it. So we look for shortcuts.

Jamis, you’ve described my current programming habits to a “T” and I thank you for all of the insight you share with the greater community. It is one of the things I most admire about 37signals, and why I keep on coming back to read what you guys have to say.

Right now, when I catch myself doing what you described, I usually stop my brain dead in its tracks by deciding it is time to do something else if for no other reason than to get my brain to reboot properly for once. After that, I tell myself just to put something out there and then get to work.

Once again, thanks for the post.

I often solve this problem by jumping into Fireworks (vectors w/ some bitmap abilities make it brilliant for this type of work) and begin putting together the draft that way. Once you “see it”, it’s easier to understand where you want get to.

Still, the problem I always have is that I still play some mind games before actually taking the app from canvas to code. To fight that problem, like you said, you just need to dive in and start writing code, whether it works or not.

Spot on!

You definitely nailed it.

Pair programming is a great way to stay true to your practices whether they’re Getting Real or XP or whatever.

Worrying about code, worrying about hot dogs, worrying about life. Silly, yeah, but some of us really like hot dogs (turkey or chicken that is ;) ). Funny thing about this, like @Grant indicated above, this must be human. For instance, I just love to travel; whether it be long road trips in the car (when gas is below $7 a gallon) or driving to the PHX airport and flying off somewhere. Strange thing the past few years (possibly due to 9/11? Not sure; ask my therapist, I will) is that I just abhor getting ready to leave. Don’t like to pack. Don’t like to think about packing. Will stay up WAY too late watching a movie/TV, even, gasp, reading a book.

In the end, I get about 3 hours of sleep, get up early, pack for the journey, and leave dog tired. When I do force myself to prepare early, by just doing the packing and going to bed early, I sleep well and am energized for the adventure ahead.

None of this probably applies to this thread, but it was my first reaction. Great weekend to all!

I get this anxiety, too. I know exactly where I have to start- as if that’s an acomplishment -but hold off on getting my hands dirty. Forcing myself to dive right in almost always results in getting into the ‘zone’ so I can make what turns out to be quick and simple changes. So, like any anxiety, this can be overcome.

I don’t find myself spinning, rather I find myself procrastinating: there’s always another piece to improve, enhance, debug, profile… and the trouble spot just churns away in the back of my head.

Usually the problem is that my gut says, “There’s an elegant way to do it, but all I can come up with is the brute force approach, and the brute force approach is work.”

About half the time, there is a clever, elegant way to solve the problem, and giving it time to bubble up will help provide the nice solution.

The other half of the time, I eventually have to take the brute-force approach, that involves a nasty refactor, a new family of classes, adding a fist-full of parameters to a fist-full of routines, and the work gets done.

Was the procrastination well spent? About 85% of the time, because there’s still practical things to do. Other times, I would have been better just plunging in the first time.

Thanks for share. Right it’s “ad nauseam”, I’ll avoid that too

Sounds like a discipline problem, rather than not following a methodology.

I do exactly the same thing, although I tend to get stuck in normalising databases and sometimes find it hard to even get to coding lol

OMG I have this same issue so much lately. And it is so true what you said about just getting on with it. Sometimes the failing early is actually just what I needed to figure it out.

Congratulations for reaching the productivity equivalent of the Berlin wall, commonly brought on by object-oriented and obsessively re-factored coding languages, such as Ruby on Rails. When you have to worry how some module is going to interact with all the other purposes it’s going to be re-purposed for, development suffers.

Go procedural PHP or similar for a week. It’ll snap you out of the funk in a jiffy. Start scribbling out procedural code purpose built for only your app, the programmer’s equivalent of a designer grabbing his pen and pad, then move those functions into OOP class methods for modification when needed as the first post-release upgrade; that’s how I snapped out of it this morning. :)

Hmm…I thought UI always led in 37signals development? Sounds like this is the inverse….

I get into the same trap. My solution, git branches. I seriously think that good code versioning is the best defense for this type of a trap.

Joshua, The guys at Grockit and Pivotal Labs do remote pairing. They are both “strict” pair programming shops.

@Keith I do the paper and colored pencils thing too. The more I find that people are as visual as I am, the more excited I become.

@Jamis I wanted to get a game and its engine perfect so I started it and restarted it and restarted it. This problem is sorely present for indie game developers.

Speaking of “nearly 4 years of drinking the Getting Real message”...

My girlfriend is getting ready this morning… staring into the mirror. (She’s gained a little bit of weight – but still beautiful.) She goes, “OMG, this bra doesn’t even fit anymore.”

Without hesitation and with a big smile on my face, I reply, “Hey, scaling issues; that’s a good problem to have.”

Sounds like a discipline problem, rather than not following a methodology.