

Ask YC:  How to avoid never-ending "design" process? - endlessvoid94

I'm taking part in an open source project with a group of students.  I've done lots of software development but the particular group I'm leading seems stuck on design decisions.  We spend every meeting arguing about the correct architecture and I don't know what to do.<p>Since we never get much done, I fear we're going to stall and never get off the ground.  How can I get this going and get some newcomers experience in software development?<p>Thanks for your advice.
======
mpjolk
It's a human-factors problem. Something is making the team unable to make a
decision and hold to it.

My guess is that people fear to commit to a path -- endless noodling in search
of a perfect solution is an efficient way to avoid the risk of actually doing
something. "The perfect is the enemy of the good". If you build in in your
head you are never confronted with the ways that it sucks.

If you're leading the group, the solution my be in your exerting firmer
leadership, by setting a go/no go point for design decisions and shifting from
planning to executing. Some kind of hell may break loose when you do it but
this may tell you what the problem has been, e.g., group members who don't
accept that there is a leader (you) etc. This is better than being in
planning-loop hell.

I like tjpick's idea. I would amend shutter's comment to say "get your stuff
out the door or fialure is certain".

~~~
endlessvoid94
Thanks, that's pretty helpful. There are people who are prone to arguing just
for the sake of arguing, which is really detrimental to the group and they
don't even know it.

------
shutter
Just come right out and say it -- show them advice from agile developers
(37Signals, etc) that says "get your stuff out the door or you may not
succeed".

Architecture can be flexible -- applications will evolve with growth. As
noodle said, commit, build, iterate, repeat.

------
noodle
you're not very specific on what you're already doing, so this might be what
you're doing already.

i would say that you should get them to agree on the most basic of
components/ideas, commit to it, and then build it. repeat. iteratively design
and build features. try and force them to design what is in front of them now,
not design the product now for 10 features in the future, or design the entire
project before building it out.

------
tjpick
The person with the code wins the argument.

------
known
I think it depends on your priorities. Features or Performance or Usability

------
known
Tell them "Show Me The Money"

