Start In The Middle

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

Pour the cool milk over the golden roasted flakes

Sprinkle the one allowed teaspoon of sugar over the top

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:

Fire up your IDE and start a new website project

Whip up a login page and get the user account basics set up

Decide OpenID’s really where it’s at these days and hit stackoverflow for a good OpenID provider plugin

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:

Google for some bayesian filter code

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

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.

59 Responses

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 🙂

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.

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?

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*…”

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.

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.

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

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%.

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.

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”.

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.

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.

“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.

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.

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…

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.

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.

[…] 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 […]

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

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.