yield thought

it's not as hard as you think

Start In The Middle

with 58 comments

I start in the middle of a sentence and move both directions at once.
— John Coltrane

Newspaper reporters are taught to write fractal articles: summarize the entire article in the title. Elaborate a little in the first sentence, then fill out the most important details in the first paragraph. A reader should be able to stop at any point without having missed any important details. We should approach programming projects in the same way.

As a child – after some experimentation and a lot of thought – I decided the best way to eat cornflakes was as follows:

Cornflakes, by Mike Haufe

  1. Pour the cool milk over the golden roasted flakes
  2. Sprinkle the one allowed teaspoon of sugar over the top
  3. Start eating around the edges, saving the sugary middle section for one last big spoonful of joy at the end

I stand by that decision. In fact, I’ve noticed I do similar things in other areas of my life. I’m sure a psychologist would talk for hours on the subject. Luckily for you I’m not a psychologist, I’m a programmer. And it turns out that this is an awful way to work on software projects.

Has this ever happened to you? You wake up one day with a great new idea for applying bayesian filtering to twitter streams to filter out the pictures of Joel’s new puppy spam. You’re totally convinced it’s what the world needs. It’s the startup that’s finally going to help you to break out of your day job maintaining PHP payroll software stock supermarket shelf stockers. So what do you do? You do this:

  1. Fire up your IDE and start a new website project
  2. Whip up a login page and get the user account basics set up
  3. Decide OpenID’s really where it’s at these days and hit stackoverflow for a good OpenID provider plugin
  4. Run into problems getting it to accept Google accounts and spend half the night debugging it

Wait, what? How did this happen? Getting OpenID working isn’t fun. It’s almost the definition of not fun.

I didn’t want to do all this, I just wanted to make an awesome bayesian twitter filter, but somehow there’s all this stuff I have to get through first.
— Me (swear words redacted)

My hard disk is littered with projects that I started, got half way through setting up without ever really getting to the good bit, then abandoned. I suspect yours is, too.

The right way to start a bayesian twitter filter is to apply a bayesian filter to content from a twitter stream. I know. It looks like this:

  1. Google for some bayesian filter code
  2. Dump whatever’s in your twitter client logs to a file and write three lines of python to parse it into a form the bayesian filter can work with
  3. Train the filter and see what happens

Compared to the original approach it looks awesome, right? So what stops us approaching all projects like this? Well, there’s something beguiling about wanting to get the framework right from the start this time. It’s more comfortable starting with something we already know how to solve. Sometimes we have a clear vision of how it should end up in our heads and simply start to create that vision from the beginning through to the end.

Start in the middle
— Paul Graham (lightly paraphrased)

Lean startups and the Minimum Viable Product are all about starting in the middle. Paul Graham’s advice for startups can be summed up as ‘first solve the interesting part of the problem, then build the business around it’, but the process is also fractal – starting in the middle applies right down to the level of writing a new class, or a single function. First write some code that solves the problem even if it’s imperfect or partial, then expand it out with your favourite blend of accessors, inheritance and polymorphism (Note: don’t even bother with that bit unless you hate yourself).

I’ve seen four key benefits to starting in the middle:

Benefit 1: Ideas that turn out to be impossible or just plain bad are discovered early. This is classic lean startup advice: fail early.
Benefit 2: Spend most of your the time solving interesting problems and not fine-tuning framework skills. Which would you rather get better at?
Benefit 3: Discover interesting things while your project is still young and flexible enough to adapt to them.
Benefit 4: Once you’ve solved a problem, you’re so motivated to use it that you finish up the surrounding areas in no time. You add extra users because you want to show it to your friends; you add keyboard shortcuts because you’re getting tired of using the mouse all the time. This is programming the right way around – first the need, the desire, and then the solution.

I’ve recently seen all of these benefits while working on my own side-project-turned-startup. Ages ago I had this great little idea for making profiling so simple that it just told you which line of code was slowest in a nice little report and I whipped up some C# code to do just that. The results weren’t making much sense, so I tried plotting the data to a canvas to see what was going on. Pretty soon I was looking at a poor man’s sketch of this:

Visualizing a program's execution

Instantly I knew I’d been working on the wrong thing; seeing the execution of a program laid out before me in all its glory was so rich and so interesting; something I had no hope of summarizing in a small table of figures. I just had to explore it – I added function names, colour, a breakdown of time spent in each and over time it grew into such a valuable part of my toolkit that I’ve started sharing it with the rest of the world.

Would I have changed direction if I had already created a website, a login system, a messaging layer, a database schema all geared around the original idea? No. I’d have reached the interesting part of the problem with a half-finished framework and close to zero energy and enthusiasm. The discouragement at seeing the futility of my cherished profiling-via-pdf idea would’ve seen me put the whole thing back on the shelf and go play Altitude to forget about it.

So start in the middle, start with the interesting, challenging, core of the problem you’re trying to solve. Cut down everything else to ridiculous minima and see what happens; you may create something fascinating.

Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!

About these ads

Written by coderoom

May 18, 2010 at 9:26 am

58 Responses

Subscribe to comments with RSS.

  1. Thank you. You opened my eyes.

    Juanra

    May 18, 2010 at 12:37 pm

  2. You do have a point there. I too end up sometimes leaving projects behind because i tend to want to make it perfect the first time around. It’s something i have to learn to control. Thanks for posting :)

    Pedro Assunção

    May 18, 2010 at 1:23 pm

  3. Good article. Thanks for sharing this insight with the world.

    Angel

    May 18, 2010 at 1:44 pm

  4. It sounded so appealing & intuitive that I couldn’t resist posting a “Thank you”. And with that, I end up sounding like cookie-cutter spam.

    Rajeev K

    May 18, 2010 at 1:45 pm

    • Except spam is never self-deprecating :-) All the notes of thanks are deeply enjoyed (and are also somewhat humbling)

      coderoom

      May 18, 2010 at 1:49 pm

  5. You’re a genius :)

    Matt

    May 18, 2010 at 1:45 pm

  6. Interesting – this problem has never happened to me. I’ve worked on lots of personal projects, and I always started with the interesting bit – it strikes me as very odd to do otherwise. First, you crack the hard part of the problem, to see whether the entire project is feasible. Then you flesh it out a bit more. Then you add some structure to make it a product, not just a proof of concept.

    steveko

    May 18, 2010 at 1:47 pm

    • /sigh if only I’d worked with you after university you could’ve saved me a decade of wasted time…

      coderoom

      May 18, 2010 at 1:51 pm

      • I’m not claiming any moral high ground or anything, but…how do you start a project thinking “oh I have an idea for a rendering engine”, then immediately start coding file I/O for 2 days? Don’t you want to get your idea down in code?

        steveko

        May 18, 2010 at 2:01 pm

      • Well, if you have to ask…

        For example, I’ll have a lot of times where I have an idea for a gameplay mechanic, and I want to whip up a little bit of an engine to support testing out this mechanic… but when it comes time to write the rendering code, I check out the state of the art and end up wanting to spend a lot of time experimenting with writing renderers. This is a little bit different from OpenID (renderers are fun and interesting to work on or they wouldn’t be quite so distracting) and of course I *should* just be starting with an existing engine and planning on rewriting some or all of it *if* my experimental mechanic goes well (especially because this is a big “if”)…. but the point is that any programming project can bring in a lot of unsolved problems (which may or may not be themselves interesting.)

        Keeping focus can be hard if you get into the mindset of “well, to *really* gauge this idea, I’ll need this other part eventually *anyways*…”

        Josh

        May 18, 2010 at 3:07 pm

  7. [...] full post on Hacker News If you enjoyed this article, please consider sharing it! Tagged with: Middle • [...]

    Start In The Middle

    May 18, 2010 at 1:52 pm

  8. reminded me of star wars – start at episode 4

    ianchanning

    May 18, 2010 at 2:11 pm

    • Hey, yeah – I should add George Lucas to my quotes somewhere!

      coderoom

      May 18, 2010 at 2:15 pm

      • May be this should be called the Star Wars principle…

        ecaradec

        May 19, 2010 at 11:24 am

  9. If you’re building a mass market product, start with the UI. It has to be simple and so it automatically constrains the problem.

    xofis

    May 18, 2010 at 2:48 pm

    • 100 times yes. The neat trick about UI first approach is also that it naturally makes you think of who is going to use it and why they would want it, what level of control/detail they need..ie: what is the essence of the idea. Even in early development you can fake/simulate the stuff under the hood and still make usefull demos/user tests.

      oliver

      May 18, 2010 at 7:07 pm

  10. It’s an interpretation of RUP :)

    laur

    May 18, 2010 at 2:53 pm

  11. I’ve always done this, but it also sometimes adversely affects my projects. I.e. I do the middle, interesting part first, then lose interest because all I’ve left is the boring stuff…

    Dirkjan Ochtman

    May 18, 2010 at 3:00 pm

    • Somehow both seem to apply to me :-)

      First I experiment with the interesting “middle”.

      Then I quickly decide that for this I need to choose a gaming engine (or framework or whatever) en spend a weekend exploring PyGame, cocos2d, Love and new fancy JS in browser engines or HTML5. Not being able to either decide on, nor master any framework.

      And then another project pops up in my head…

    • I’m hearing you there. Happens to me aaaaall the time.

      Tool

      May 24, 2010 at 9:48 pm

  12. It may not have been the first time I’ve heard this advice, but hopefully it won’t be the last, either. This is one of those things that every programmer seems to resist intuitively (despite being completely wrong to do so) and every reminder helps us to excise the bad habit. This one was particularly well-written, too, and had a Coltrane quote that broke my pre-coffee English parser to boot. Thanks

    Josh

    May 18, 2010 at 3:01 pm

  13. A different approach, I wonder if that would work, I start a lot of things, and get sidetracked somehow….driverguy7.wordpress.com

    driverguy7

    May 18, 2010 at 3:28 pm

  14. I like the idea of starting in the middle. Often do that when prototyping an idea

    steve

    May 18, 2010 at 4:06 pm

  15. I was thinking the same thing this weekend. I had great ideas, momentum and will to do stuff, but suddenly there were all these other parts surrounding and killing it all. ‘Don’t slow down!’ I thought. ‘Focus on whats important! What is the most solid and bestest place to start?!’ etc.

    Truth is, at times its hard to know the answer to these questions. But still, the rest of the time, its easy(ier). The answer is hitting you in the forehead.

    Your damn right when you point out that we seek to do what we know instead of expanding into new territory. We also want everything to be perfect form the start. A solid ground.

    This craving for perfection, is it part of a humans “fear of losing”? We can’t let it be before it looks, acts and feels all 100%.

    Fred Carlsen

    May 18, 2010 at 4:26 pm

  16. Spot on, mate! Couldn’t have said it better myself. (And it also took me about a decade to reach the same conclusions.)

    steve

    May 18, 2010 at 4:48 pm

  17. your post made REDDIT!

    i work in the industry of cognitive science and found your article refreshing and pleasant.

    your article prompted me to share what i’m sure anyone wishing to learn more about this kind of thinking would love to learn. i reference your article, and expand further on more ways to better streamline your internal programming to better achieve the results you want.

    http://www.reddit.com/r/programming/comments/c5ibi/start_in_the_middle/c0q9a66

    p3ngwin

    May 18, 2010 at 5:20 pm

  18. I’d rather call this article “Start small”, or “Build now, fix and enhance later…”

    Actually the latter is the strategy I adopt in all my projects, I don’t care if the end result is ugly, or missing a lot of the features, but at least just get something out. Later on you can add more features and enhance the look and feel of the end product. Another benefit is “No frustration for the programmers”.

    PM Hut

    May 18, 2010 at 6:42 pm

    • the thing is, this process doesn’t care about size or effort, it depends on the “value” of what’s most important to you.

      if that means the large chink that’s going to take a long time and effort, that’s what you’re going to love to chew on, even the there are smaller and easier bits that are boring.

      p3ngwin

      May 18, 2010 at 6:56 pm

  19. It seems so obvious, and yet we usually don’t think of it. Well said.

    Matt

    May 18, 2010 at 6:44 pm

  20. I am going to revisit the projects I left behind

    Prosper

    May 18, 2010 at 7:30 pm

  21. I think it also depends on the scale of the project, and how far through it you are. For prototyping something up quickly, then, yes! Definitely the middle is an awesome place to start. You’ll soon find out what is/isn’t working.

    But once that’s done, if you really want to flesh it out into an application, then starting from the beginning with proper planning and requirements gathering is also going to make your life a lot easier and less painful.

    If you design your application interface around the awesome cool algorithm inside, it may work for you (hey, you built the thing! Of course you’ll know how to use it) but other people may not find it so useable. It’s in this case that time spent getting OpenID to work *is* valuable.

    But either way, great read!

    Sam Dalton

    May 18, 2010 at 7:57 pm

  22. Excellent article. I’ve experienced what you describe a thousand times already, I even have that projects folder full of half-baked frameworks you mention.

    I’ll take your advice for the next time! Thanks for the insight.

    Regards,
    Santiago.

    Santiago

    May 18, 2010 at 9:03 pm

  23. I’ve been meaning to start up a web app and have day dreamed about it and sketched it out all day while at work. But when I get home I’m disinterested and just play Altitude… I think I’ll get to work on that web app now.

    Devon

    May 18, 2010 at 10:39 pm

  24. “fractal” in the intro isn’t the right word; you probably mean “inverted pyramid”. But you should have cut the first 3 paragraphs of this (at least) anyways, they’re irrelevant to your point; “Has this ever happened to you?” is a perfect starting point.

    The reference to the programming process as “fractal” is also incorrect, and ultimately ancillary to your point: the way to solve problems is to solve the problem, then embellish it in supporting scaffolding.

    jsled

    May 18, 2010 at 11:16 pm

  25. [...] Start In The Middle I start in the middle of a sentence and move both directions at once. — John Coltrane Newspaper reporters are taught [...] [...]

  26. This is a pretty good formalization of what I’ve been trying to tell people my entire career – well done writing it such clear language.

    TML

    May 19, 2010 at 3:00 am

  27. This is the old idea of “The best is enemy of the good”

    Jose Luis Casado

    May 19, 2010 at 8:20 am

  28. There is a name for what you describe: “Agile.” Agility is all about producing value first. Agile methodologies (such as Scrum) focus on getting something that works and iterating over that adding features in a priority basis. In your case, OpenID is lower priority than the spam filter since the filter was the main problem you were trying to solve.

    Talbott Crowell

    May 19, 2010 at 11:22 am

  29. Interesting concepts. Thanks

    vlain

    May 19, 2010 at 11:26 am

  30. An important step is the one where you tell the world of your project. I think that’s the step that keeps you motivate to pursue working and building the extra layers.

    If you loose interest after building the middle stuff, try announcing it to the world.

    ecaradec

    May 19, 2010 at 11:32 am

  31. Great article. This is a eye opener. I think this should be the right approach for developing a software.
    Thanks.

    R.Choudhury

    May 19, 2010 at 1:45 pm

  32. Start In The Middle…

    Lean startups and the Minimum Viable Product are all about starting in the middle. Paul Graham’s advice for startups can be summed up as ‘first solve the interesting part of the problem, then build the business around it’, but the process is also fract…

    The Startup Arena

    May 19, 2010 at 2:34 pm

  33. You know, the times that I have been most successful at any IT project were when I did just what you are saying here.

    Because I am a designer and a learning programmer in one, I tend to be caught up in the look and usability of the project rather than getting to the meat of the solution first. But when I condition my mind to forget looks and hit the problem first, I end up with a surprisingly good-looking solution and not a good-looking potential solution.

    Thanks for sharing.

    O'Neil

    May 19, 2010 at 2:48 pm

  34. I’ve always written software this way; I do the good bits first — starting from the middle. My real problem is I usually give up when I get to the uninteresting bits. Having already solved the problem, I’m done, and mentally have moved on.

    Erik

    May 19, 2010 at 5:03 pm

  35. [...] Start In The Middle I start in the middle of a sentence and move both directions at once. — John Coltrane Newspaper reporters are [...] [...]

  36. [...] someone had sent me this earlier in the week I could’ve saved us all 1093 words. Much love to Craig Lyons and some random youtuber for the startup anthem of the [...]

  37. Not only are you pursuing the high value stuff first, but you are pursuing most likely the riskiest stuff first by using this approach. Great post!

    Paul

    Paul Boos

    May 20, 2010 at 1:15 pm

  38. [...] didn't write a post last weekend and I've been feeling kind of stuck. Reading this article helped me to refocus a little. I'd been thinking too far ahead, worrying about advanced features [...]

  39. [...] try to plan everything out ahead of time and then trudge through implementing it. Rather, I start in the middle, always with an eye toward adding the next useful feature. Right now I find myself really wanting [...]

  40. About Ittefaq (www.ittefaq2.com)

    The daily Ittefaq – The Daily Ittefaq (Doinik Ittefak) is one of the
    Bangladesh most published and circulated newspapers. Ittefaq is covering local news, sports, business, jobs, and
    community events. Tag : Ittefaq, Daily Ittefaq, bangla, daily, newspaper, Bangladesh, dhaka

    Ittefaq

    May 27, 2010 at 11:01 am

  41. I want my cornflakes with strawberry jam. No sugar, no beer, sometimes few drops of vodka.

    Jack Bauer

    May 30, 2010 at 9:35 pm

  42. As always, I’m astonished at the reactions containing the word “I” multiple times. Don’t you people (also the original writer!) work on teams – so it is always a “we”? However, this complicates matters quite much, as the team you’re a member of must agree (mostly) on what the “good pieces” are … The guy who said “Scrum” got it right; but if you work on a scrum team, you find that it still takes time and understanding and passion and tolerance to gravitate towards the “good pieces” at the right time.

    Harald Müller

    June 21, 2010 at 11:22 am

  43. [...] discussion reminded me of a post titled Start In the Middle I read a while ago. In there, it offers a bit of advice that should be obvious that is so often [...]

  44. [...] This is known as starting in the middle. [...]

  45. I agree. Fascinating read this.
    *checks system for unfinished scraps*

    Deboshree

    December 18, 2010 at 11:28 am

  46. [...] I have opted for the Start in the Middle approach. I have an idea, I have focused on the primary objective of that idea and started the [...]


Leave a Reply

Please log in using one of these methods to post your comment:

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 32 other followers

%d bloggers like this: