Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do it or document it?

news.ycombinator.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Do it or document it?

#11

Post by Neoryder »

ajross wrote: post #5
mechanical_fish wrote: post #3

Napkins. The solution you're looking for is napkins. But, it's true, they're hard to write on, so we'll compromise. Take a pad of paper and a good pen ( hint: Pilot G2 ) and go to a place that is entirely free of computers. Coffee is optional. Start sketching. Your goal is a set of notes, an outline, a diagram or two, and/or some paper-based UI wireframes that describe your project. Imagine that you're trying to invi…

Yeah, indeed. The word to eject from the process is "formal", not "documentation". Write stuff down however it works for you: be it email, IRC logs, napkins, whiteboards, whatever. Refine as needed. Write summaries every few ideas. If the problem is of the right size, bang out prototype scripts and let these serve as "documentation" too. But scrap the endless cycles of proposals, reviews, designs and revisions. Do th…

Yes I think this hammers an important point. Write with what helps you think, For me It has to be an uber size blank sheet of paper and I just start planning. After the paper I can usually go to a laptop an either make a rough prototype or at least a structure in code. I don't know why I can't seem to code directly.

To repeat do what helps you think faster/clearer/better

Re: Do it or document it?

#12

Post by rmenke »

Depends on your expected rate of growth, and how much time you expect each developer to waste in bootstrapping and mentoring. When you consider getting your third developer, then is the time to start thinking about documentation processes (as in managed and computer-accessible, not Z or UML).

Having been the second in a few startups, I can tell you that not having any sort of documentation is annoying. Do not expect anyone to read your code and understand how your mind works: if you don't document, you will have to sacrifice a significant amount of time training the new employee. You'll have to hire during a lull, and in a startup there's never a lull. As usual, Fred Brooks said it first.

Finally, Twitter is a good example of what acting first then designing second can achieve: unfixable scaling issues. Don't do that.

Re: Do it or document it?

#13

Post by Kaizyn »

You will have to look at documentation like everything else having to do with your startup. Document only if it provides a high return on your time and resources. Ask yourself at each point while you work on your project: 'What can I do now that benefits my business the most?' When the answer is documentation, then document. That's a major benefit of running your own business: no one gets to dictate your priorities to you. So enjoy that freedom.

Re: Do it or document it?

#14

Post by eru »

ajross wrote: post #5
mechanical_fish wrote: post #3

Napkins. The solution you're looking for is napkins. But, it's true, they're hard to write on, so we'll compromise. Take a pad of paper and a good pen ( hint: Pilot G2 ) and go to a place that is entirely free of computers. Coffee is optional. Start sketching. Your goal is a set of notes, an outline, a diagram or two, and/or some paper-based UI wireframes that describe your project. Imagine that you're trying to invi…

Yeah, indeed. The word to eject from the process is "formal", not "documentation". Write stuff down however it works for you: be it email, IRC logs, napkins, whiteboards, whatever. Refine as needed. Write summaries every few ideas. If the problem is of the right size, bang out prototype scripts and let these serve as "documentation" too. But scrap the endless cycles of proposals, reviews, designs and revisions. Do th…

Wikis work good, too.

Re: Do it or document it?

#15

Post by eru »

rmenke wrote: post #12

Depends on your expected rate of growth, and how much time you expect each developer to waste in bootstrapping and mentoring. When you consider getting your third developer, then is the time to start thinking about documentation processes (as in managed and computer-accessible, not Z or UML). Having been the second in a few startups, I can tell you that not having any sort of documentation is annoying. Do not expect…

Is Z still used? I once read a book about it - but that was some time ago.

Re: Do it or document it?

#16

Post by [deleted] »

eru wrote: post #14
ajross wrote: post #5

Earlier quoted context omitted.

Yeah, indeed. The word to eject from the process is "formal", not "documentation". Write stuff down however it works for you: be it email, IRC logs, napkins, whiteboards, whatever. Refine as needed. Write summaries every few ideas. If the problem is of the right size, bang out prototype scripts and let these serve as "documentation" too. But scrap the endless cycles of proposals, reviews, designs and revisions. Do th…

Wikis work good, too.

[deleted]
Post reply on HN