Hacker News new | past | comments | ask | show | jobs | submit login

At a strategy level, which one of the two points you end up doing depends on who commissions and evaluates the work. If someone hands you a spec and then disappears, only to come back 5 years later and expect to receive a finished project, you'll be working "top-down". If you're trying to solve someone's immediate problem with software, and are in regular contact with that someone, you'll be working in "rapid prototyping". All projects, software or otherwise, are spread around the spectrum between the two endpoints. Where exactly depends on specifics, but if you're starting a new project, the consensus is that you should aim to be closer to the "rapid prototyping" end.

At a tactical level, feature level, you mix both. You state your problem (or get it stated to you), you think it through, hopefully considering at least some related work and doing some hard thinking, come up with multiple possible solutions and evaluate their trade-offs... by implementing their prototypes as fast as possible, because that's the only real way to discover the trade-offs. Depending on how much in a hurry you are, you might pick the first prototype that isn't a total disaster and build your feature from it, then test it, and repeat.

See how "top-down" and "rapid prototyping" is interwoven here. This approach can be expressed as: think before you do, but remember that you only learn the true scope of a problem by attempting to solve it.






Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: