Kyle Posey 16 Jan 06

Ahh, finally something I’m already doing right…

Noah Winecoff 16 Jan 06

Yeah ditto, but its good to see it from a respected source. Thanks Matt.

Boris 16 Jan 06

Funny, I’m working on a huge project. We are trying to get it funded. This takes a while as you can imagine. Out of frustration I decided to take a very small part of our project and just build it. I had a domain sitting around which I could use and just started in the middle on friday! Sunday evening I was finished and launched an almost finished project, in beta ofcourse. It made me feel real good to build something and just start somewhere instead of only planning, lunching and talking. Thanks for the post…

Dennis Pallett 16 Jan 06

Hear hear!

This is really good advice, and applies to almost anything. If you’re stuck on the beginning, trying starting somewhere else, even if there’s the chance that you have to redo it later. It’s better to get the wheels in motion, than to stay stuck.

Emile 16 Jan 06

I would consider this a method of brainstorming n’est-ce pas? I like to do this… often, but it can also be a backdoor to hell if not done cautiously. Most especially with software, engineering, and the like. Jumping in and getting to it can help one produce a product, but not necessarily the best product.

6Ps = Perfect Preparation Prevents Piss Poor Performance�(I wish I could trademark that)

Then again, there’s something to be said by not getting stuck in always planning and never doing and in such cases I think your post hits home quite nicely!

Bryan Bedell 16 Jan 06

That goes along with the “limitations inspire creativity” idea; often a project with what appear to be restrictive limits (budget, schedule, creative elements, etc) encourages creativity more than a client who says “just make it cool!” (oh how I love that phrase, as if their “cool” and my “cool” hang out at the same record store). Sometimes it’s up to you to put unrealistic limitations on yourself, rather than start out with a blank slate and the infinite amounts of directions (and time and work) that a blank slate allows.

brad 16 Jan 06

I can do this with some kinds of projects, but for writing I usually need to nail down the lead first before I can move on, because the lead sets the tone and in some cases the direction, and everything else flows from there. I find that jumping into the middle of an article before I’ve written a good lead is like trying to build a house without a foundation…I always feel like I’m on shaky ground.

Tom Watson 16 Jan 06

Simple post but one that really resonates with me. I often find myself needing to work through the project in the “right order” as opposed to just sitting down and working on the project itself.

Jeremy 16 Jan 06

It could be noted that this is the basic premise of various forms of Extreme Programming - once you strip away the management rubbish around the edges: 1) Vaguely define what you want some software to do. 2) Write the most basic code that acheives that objective. 3) Get immediate feedback from clients, redefine your objectives as necessary and re-factor your code as necessary. [4) Profit! - Sorry, obligatory /. gag needed]

Thanks to great languages like Ruby and Python, there’s no point sitting about is meetings designing structures and implementations. Get out there, write something, make it big, realise some fundamental assumption you made is wrong, re-write it from scratch with all your knowledge from the first time, make it the best product ever. It took you less time than planning, specifying and developing, and you learnt from your mistakes in the bargin. What’s to lose?

Disclaimer: I don’t, unfortunately, manage to do this. I mostly sit around twiddling my thumbs worrying that any code I write wont work properly with full i18n in Chinese 12 months down the line, or might cause some slow-down when installed on 50 servers with millions of users… If I just wrote code, however unforseeing at the time, and re-writing it later, I’d be a less fustrated programmer and no doubt more productive to boot.

Mike Rundle 16 Jan 06

Ah, good to see a Britt article at SvN. He’s a good guy, really funny too. Britt, are you going to be at SXSW in a few months?

Britt 16 Jan 06

As I think about this even more, I’m already beyond starting projects in the middle. I’ve realized they really start at the end. Whether creating a software application, screenplay, or dinner, we usually have a good idea in mind of what the finished product will be.

Granted, it might seem difficult to start working on the end of every project, but, using the examples above, let me illustrate.

Software application: You could start by writing documentation about how to use your product. Let’s say you were looking for an online project management application. Everything you tried (this example is pre-Basecamp) was too cumbersome, confusing, or expensive. Rather than breaking out your books of code, you could start by writing documentation for the application you would like to use.

Screenplay: Many screenwriters know how their movies are going to end. In fact, the beginning of a movie is the part that will most likely change in the rewrite. The end rarely does. Check out the draft and finished examples of American Beauty.

Dinner: In order to help visualize the outcome of a successful dinner for my wife, I set the table first and then start cooking. After too many times cooking and then rushing to set a sloppy table, I realized setting a nice table first helped me relax more during the cooking process and have a much better outcome overall.

But I still do like to jump in the middle sometimes.

And, unfortunately, no, Mike, I won’t be making it to SXSW this year, which saddens me. I’ll miss you guys.

Simon 17 Jan 06

Hey! Thanks for the “epicenter design” link. I’m working on a pretty complicated new invention (a toy) which every now and then stalls because of some issue or other. Your previous post and the comments to this one are very useful!

sb 17 Jan 06

brad- i find the opposite in writing, start with what comes out, don’t force a lead. that constrains the article to the lead. i can’t tell you how many times i begin an article only to realize i’m writing a different article than i set out to write. often a better article.