from Hacker News

Write a rapid prototype first (2007)

by throwaway3157 on 3/11/20, 3:17 PM with 17 comments

• by CptFribble on 3/11/20, 9:31 PM

  To echo other comments, I've found this works for creative/fiction writing as well.

  I forget where, but I once heard that writer's block is what happens when you try to create a final draft on the first try.

• by olegious on 3/11/20, 4:32 PM

  This is great advice for almost any problem, not only math. I've used the same approach when programming, thinking through product problems, even thinking through issues that come up in life- describe the problem and the outlines of potential solutions. I find this brings clarity that's not always present if I just think through problems in my head.

• by hcarvalhoalves on 3/12/20, 2:41 AM

  The tips on how to prototype are very good. Let me give another perspective though:

  You shouldn’t always prototype first, before mapping what kind of problem you have, at the risk of reinventing the (square) wheel.

  Rapid prototyping is the holy grail software is known for. But prototypes are not always cheap, and almost always go to prod and turn into technical debt. In other disciplines the instinct to just try something first would sound ridiculous (e.g. let’s always figure out open heart surgery from scratch, it’s just a quick experiment, if the patient dies we figure out later).

  I’m a fan of the Cynefin framework [1] as a higher level tool to figure out if I should prototype at all - even if not very precise, because at least it forces me to think about it.

  [1] https://en.m.wikipedia.org/wiki/Cynefin_framework

• by codr7 on 3/11/20, 9:47 PM

  I do this with code, which is my main creative medium these days.

  First I solve the problem, without giving a damn about anything else.

  Then I gradually improve my solution until I understand the problem well enough to drastically improve the architecture, at which point I either refactor or start over from scratch depending on which takes less effort.

• by fooker on 3/11/20, 11:18 PM

  I am a big fan of this approach.

  I have seen that if I stop and think about the problem too much in the beginning, it takes a whole lot longer to arrive at a good solution.

  Prototype -> Think -> Engineer.

  If you are lucky, you get to reuse some code from the prototype, if not that was hopefully a good lesson for the future.

• by phsource on 3/11/20, 6:28 PM

  > In particular, it is often difficult to make the (important) decisions about the organisation of the argument, and selection of good notation, until a large part of the paper is already written

  This is very true. When writing a blog post in China during the earlier parts of coronavirus [1], I had drafted an initial version where I just went through my experiences in chronological order. Only after writing it all down did themes emerge in how I finally structured the article.

  This really speaks to the power of interdisciplinary concepts though. Writing an essay by writing an outline first and then filling in the details probably predates rapid prototyping by eons. It's cool that it all circles back to writing academic papers only through this leap!

  [1] https://wanderlog.com/blog/2020/01/29/coronavirus-observatio...

• by bigiain on 3/11/20, 9:50 PM

  I wonder how often “proof of concept” or “rapid prototype” scientific papers get “pushed into production” before they’re finished by managers?

  I wonder if papers written this way suffer from “second system syndrome”, where the rewrite stage totally changes the underlying arguments and conclusions “in response to feedback from stakeholders”?

  <grin>

• by saeranv on 3/12/20, 4:46 AM

  I find it very surprising that he suggests writing the introduction at the end of the paper. He doesn't explicitly mention the abstract, so I'm assuming the introduction includes the abstract of the paper. If that's true, I find it impossible to write any paper without first working out a fairly fleshed out abstract. It usually takes about 50% of my time to just write my abstract.

  The way I structure my prototypes, I have to have a sense of the existing state of the art, which I then leverage to propose my hypothesis. I do a version of this for programming as well, I try and identify state of the art methods in the field, and use that to guide my implementation.

• by hyperpallium on 3/12/20, 7:11 AM

  He talks about how to begin a daunting task: linear order, easiest/most straightforward first, or a top-down "skeleton" first.

  If it's daunting enough to be discouraging, consider doing tasks that quickly give you some sense of progress towards what like about it. To sustain your interest - your most precious resource.

  This mightn't be most efficient, or give the best structure, but if it motivates you to do it, it will be far more efficient and better strucured than nothing!

• by hyperpallium on 3/12/20, 6:54 AM

  > [paraphrasing] get some good idea along the way devote a minute to write down a “stub” for that (just enough to jog your memory when you return), so as not to break your concentration or momentum

  This "stub" or aide-mémoire doesn't define the idea, just evokes it. So you better come back while that memory is still fresh, or you will not be able to work out what it was!

• by underdeserver on 3/11/20, 11:01 PM

  Title missing a (2008).