
Ask HN: What's your ratio of time coding to planning? - relaunched
I'm curious as to the ratio of how much time is spent coding vs. planning at startups.  Specifically, how it changed from day 1, seed, series A, B...<p>If you have lived through and seen the changes, and can speak to why / when they occurred, I'd appreciate it.
======
X4
"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!

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

~~~
radagaisus
This. After years of writing detailed specifications I realized I'm always
stupid and always wrong. Now I plunge as fast as I can into code to find
exactly where are my mistakes.

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

~~~
wladimir
Same for me. Not that I never sit back to think of the bigger picture, but
I've learned to think at multiple levels at once, so I can think of the higher
level design while writing code / comments.

I'm usually a bit wary about planning without thinking of the code level
because it can quickly result in architecture-astronaut plans which take a lot
of decisions prematurely.

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

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

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

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

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

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

~~~
marcomonteiro
Though code is used for test cases I would consider it planning. Especially in
a TDD/BDD development process because you're taking the time to define
what/how/where/when and why the implementation you'll write after works. Just
my $0.02.

~~~
X4
I agree TDD/BDD is the result of good planning and the byproduct is a coverage
of cases into a application skeleton or bounding box.

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

------
westiseast
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').

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

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

~~~
jeromeparadis
I'm the co-founder/CTO of a startup and I agree: when I'm not in front of the
computer coding, I'm always planning.

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

~~~
gscott
To put a name to it, your using the <http://programming-motherfucker.com>
style/method.

~~~
adrianparsons
I thought the "motherfucker method" was cursing at the program until it works.
This aptly describes my style of programming.

