Ask YC: How to avoid never-ending "design" process? | Hacker News Reader

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

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.

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?

Thanks for your advice.

View on HN

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

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.

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.

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.

The person with the code wins the argument.

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

Tell them "Show Me The Money"

Reply on news.ycombinator.com