Hacker News Reader

"Either something is possible or it is not. If you don't know, that just means you're lacking knowledge (and maybe it's never been done before)."

Exactly - and that's what I use prototyping to figure out.

It's not just "is something possible?" - it's "is this possible given the time, tools and skills available to me?"

Here's a really simple example from a couple of years ago: I wanted to build a tool that exported my Apple Notes to a SQLite database.

Is that possible to build? What are the export options available?

I ended up using an LLM to write AppleScript (a language I had no prior experience with) to extract the notes data, and it worked great. I wrote up that prototyping experiment here: https://til.simonwillison.net/gpt3/chatgpt-applescript

>> "Either something is possible or it is not. If you don't know, that just means you're lacking knowledge (and maybe it's never been done before)."

> Exactly - and that's what I use prototyping to figure out.

Perhaps "prototyping" is an inappropriate descriptor here. A better one might be "one-off disposable code" considering the example described.

Peer developers could easily interpret prototyping an AppleScript ETL as only requiring minimal research into identifying its applicability and subsequent reusable definition.

However, a "one-off disposable AppleScript approach" expresses minimal investment (time) and also conveys a higher risk tolerance to potential incorrect code an LLM might generate.

HTH

"one-off disposable code" is pretty much exactly what I consider the term "prototyping" to mean.

One-off and prototype share similarities in development methodologies. But not in the long term goals.

In a one-off I don't care about a few output errors that I can fix by hand once. Good enough is enough.

A prototype requires to explore the limitations and estimate the effort required to eventually reach correctness. This estimate juggling time, cost, motivation, knowledge and "human resources" together.

One example of where software prototyping helped me was deciding which library or framework to use. At my job, I had the option of two different Futures libraries to handle async, and I had to chose which to start using.

And I went off to write like a quick version using each and when I got to trying to handle consuming pagnated responses, it was a terrible terrible fit for one of the frameworks, and required only like 20 lines in the other.

I then took that back to the planning phase and used that to decide how the entire application was going to be structured, as we didn't want two competing frameworks.

> Either something is possible or it is not. If you don't know, that just means you're lacking knowledge

It's not always you as in yourself but you as in your company or your team. You yourself might know it is possible but management might not believe in it. They ask for a prototype to get you the resourcing for the project to proceed.

Lots of people pencil sketch before they paint. It's not at all odd to whip up a prototype, a sketch of the final product. You could do that with pen an paper, in Figma, code vibe it, or whatever solution is quick and dirt for you.

I've worked directly on consumer software used by hundreds of millions of users and many people I worked with prototyped in various ways before scrapping it to write production code.

Some use cases for figuring out what is possible are when you're building something that relies on APIs (such as a chrome extension and you're not familiar with how they work / what they do or just what permissions are needed) or requires that you have certain data specific to each customer.

Every first major revision is a prototype whether you call it one or not.

The test may be to see if there's a market for the product. What you'll learn in that test is much more than a binary answer.

My understanding was that to start working on a product, you must have prospective users/customers that you can talk to to get the the gist of what they would like, the build a MVP and then iterate with the feedback you receive. In this case you already know that what they're asking for is possible or not.