[agentultra]

Prototyping is a wonderful thing we should do more of.

However, in my experience, when you take this approach the majority of organizations will make the prototype the product. You will never throw out that code. It will simply be added on to, papered over, and mixed up with everything else. What started off as a fine prototype becomes a error-ridden ball-of-mud that nobody understands anymore. Where working on that code takes longer and longer and carries a higher risk of introducing even more errors.

The key thing with prototypes is that you have to mercilessly rip that code out before people start extending it and relying on it otherwise it's going to stick around.

[sodapopcan]

I worked at an org that did prototyping and it was fantastic. It was especially great for validating if a customer actually wanted the feature they were asking for (they often didn't). We _always_ threw away the work and started fresh if they did want it. What really helped keep us honest here was that we TDD and pair programmed. We also prioritized getting the prototype finished as quickly as possible. This meant writing really horrible code, calling variables and functions things like `foo`, and breaking other features if necessary.

[pksebben]

> The key thing with prototypes is that you have to mercilessly rip that code out before people start extending it and relying on it otherwise it's going to stick around.

A way to avoid this is to start with a clearly defined data model between components, and then _within the context of each of those_ hit the gas towards an MVP, flesh that out, refactor, etc etc etc.

Not always a possibility, I'll grant, but a ton of headache can be saved by being religious about API-ifying those services which can be made into APIs. Stable I/O, chaotic move-fast-break-stuff for internals.

[moffkalast]

Recently left a company that mostly just wanted random stuff to be glued onto an early prototype for years now. It just gets progressively more and more infuriating as it almost becomes obvious that a full rewrite would take less time than adding the stupid <thing of the week> that the management wants. Doubly so with AI acceleration for new projects.

After a while it becomes impossible to convince anyone to ditch the prototype because of all the testing hours that have been poured into it, making for a very strong sunk cost fallacy.