Hacker News Reader

I agree with this philosophy as well. If is a project or program that will be worked on more as time progresses, typically it refactors itself after the programmer has a better grasp of the big picture. Often the bigger picture can only be grasped after there is some momentum with the project. I'd say this works 90% of the time, where the other 10% needs more upfront design and research done before any real work is started.

View on HN

It's rapid prototyping. It might just happen that the prototype is good enough to sell, but once you have a basis, comparisons can begin. If the prototype doesn't have to act as the real product, just a skeleton, it's not so hard to change the "bones" if something isn't working properly.

If the prototype is quickly made, it could even count as part of that upfront design process.

I like my people to do more than prototype for this kind of work. It's probably a semantics argument, but we prototype as part of design and intend for it to be trashed/rewritten, whereas what I was speaking to above is real development work that will be used, definitely not polished but 'works' enough to keep moving forward.

That often means "getting the bones" right, but occasionally cutting corners to get stuff done. If your focus is having a good product, which frankly it most of the time should be, then done is better than perfect.

Reply on news.ycombinator.com