Ask HN: What's your ratio of time coding to planning?

Usually 60-65% planning 35-40% coding.

There's two kinds of projects -- the ones who know what their solutions should look like, and why, and the ones who don't.

Most problems really end up being hammer and nails once we understand them and can make a clear blueprint.

Part of planning can often mean Proof of Concept coding / trying out some things, but not always production code.

Just because we can build a doghouse without a blueprint doesn't mean we should build a house or a factory without one.

What does writing tests count as? Especially if you're doing TDD or BDD.

I know this is really stupid and the initial quality of some of the code i write is really low but when I am just making things for fun its kind of like freestyle rap to me so 0% planning 100% coding.

http://i.crowdfunded.it is an example of this.

Putting aside BA work, I seem to do most planning in code - ie, fleshing out an example implementation in code, mocking up some models, etc. That eventually morphs into the end result. So, don't think it's as cut-and-dry as coding OR planning.

That really depends on how you define planning. Sometimes, I write code, realize I'm going in the wrong direction and need to re-plan things. Planning isn't always something you do before you put your thoughts to code.

slightly off topic, but i spoke to a Technical Department director in a Chinese computer games company yesterday about planning and length of projects etc.

He said they never have a web project lasting more than 2 weeks. ie. from planning to completion.

It's not because they're using agile methodology or iterations or whatever.... they just do things differently (and yes, sometimes that means zero planning, zero testing and generally 'worse').

It's a very tough question because 'planning' can include time when I'm in the shower, falling asleep, or driving to work. I work at a megacorp though, not a startup.

20% coding, 70% re-writing the code. Planning 10% somewhere in the middle.

In my experience, it's more or less 2 parallel processes which are very alike. If I really had to guess as to time, it's be something like:

Plan -> Code -> Refactor -> Replan -> Code -> Refactor

10% -> 15% -> 30% -> 20% -> 10% -> 15%

For me, the first refactor and replan phases take the longest time.

Planning is a wasteful byproduct of being a poor developer. A good developer will write code once, get it right the first time, without any planning, and have it do exactly what it needs to do. Everything else slapped on top of that to get from A to B is a waste of time. That includes planning. Writing tests. Coordinating meetings. Documentation. Commuting. Sleeping. Unfortunately, people have come up with things like "planning" and "QA" because they hire incompetent developers - and instead of properly getting rid of them, they hire people to fill in the gaps and flaws.

Just kidding, sort of.

My guess is that it would depend on the project. Some projects are simple to conceive of (it will be like facebook, but for cat-lovers!), easy to rough out, but more difficult to implement correctly. Other projects may require a lot of up front planning and thinking (which data structure to use? what should it look like?) but then end up being quick to code.

I've noticed that when I write programs, the more time I spend planning features and algorithms before I start writing code the less time it takes to actually create. I don't always spend a lot of time planning, though.

All time is planning. While I'm writing code is some of my most productive planning time.

Sage advice I heard somewhere: "Weeks of coding saves hours of planning."

"Pee your problems away and think ahead!"

"Ask yourself, why do you think the best ideas come when you're in the toilet?"

It sounds trivial and you won't suspect a magic or pattern behind it. You'll think it's just coincidence, but in reality you secretly remember the toilet is an awkward place where you magically solve the problems that you were stuck with all day. It's way of thinking, releasing yourself from stress to focus on the path you want to go with your planning and code, not so much theory here. It's not enforcable.

The only room, where you're alone with yourself and where you relax your inner muscles. As you know, every contraction happens in your cerebrum first, this relaxation acts as stimulus for something I can't explain.

Planning, Development, Strategy and Success aren't entirely seperate, they live in symbiotic co-existence and strengthen each other. That's why many people say "You first start coding and the rest will follow". In reality this is an illusion, you can't code without planning or strategy, it's fueled by hard trained routine and effective problem->solution matching. You know it: The more you code the better you become and success boosts you into new directions.

We've all experienced it, sometimes you're better than usual and you want that effectivity back, when you're stuck and don't know a solution. Call it flow if you want, but I think it's peeing problems away :)

My routine is to do more learning than planning. Because the more relations from very different topics I can come up with, the more effectively I can solve a problem on a special field.

Have a nice weekend!