Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

Maybe it's just me, but if I'm doing any sort of migration like this, the first thing I do is create a small PoC that emulates the full process to iron out any weird, obvious edge cases and ergonomic issues.

In this case, hitting the Lambda size limit would have been the first red flag that triggered a re-evaluation of the whole approach.

Understanding the limits of the stack (Prisma + PlanetScale) would have been obvious from a few simple toy examples.

Seems like this team dove headfirst without even building a simple toy to determine if the choice was actually viable.

View on HN

I am amazed at the number of engineers I've worked with who jump straight into the full implementation. I've done it myself on a few occasions thinking "how hard can this be".

Building the "toy" first is great.

In my experience, about one third of the time the toy is all you need, you can stop there, and what you were going to build fully would be over-engineering. About one third of the time, building the toy tells you you're taking the unworkable approach as you mentioned. And the other third of the time you can extend the toy.

I have a directory on my drive called `sandbox` where I basically throw together small toys for anything with some unknown complexity. Anything from how an ORM might model a specific type of relationship (throw together a basic replica with a Docker compose file) to replicating the deployment model (poking AWS Copilot, for example) to testing out some tooling flow (e.g. local build process change).

The main thing with a toy model is speed. You can build/deploy/test with a smaller scope and progressively scale it up some reasonable scale of the full thing (whatever you're testing for) and you can iterate your testing faster. But many times, the key issues show up quite early in the process of grokking the toy model.

I too have this "sandbox" directory. I use it for what you say. But also for troubleshooting, bugreports or a stackoverflow question.

Just throw up a new project, hack around in it for an hour, and most often the problem/bug in my original code becomes apparent because of the isolation. I'll easily write four such sandbox projects per week.

'scratch' for me. Everything from quick regex tests to full library rewrites tend to start there.

> In my experience, about one third of the time the toy is all you need, you can stop there, and what you were going to build fully would be over-engineering.

On the flip side, the cases where the toy ends up being promoted to production service end up being riddles with technical debt, missing features, and buggy behavior that jeopardizes the whole project, also happen.

Survivorship bias is also a major problem. It's easy to presume that the winning bet you took is the right path.

This scenario emerges as often when starting from the toy as it does starting from the "correct" full implementation.

Sometimes the toy becomes the full implementation.

yes hopefully, that's the best scenario.

> In my experience, about one third of the time the toy is all you need, you can stop there

In my experience, about two-thirds of the time management sees the toy and ShipsIt thinking that's all you need.

Nothing wrong with that if the toy meets all of the functional and non-functional requirements.

If you find offense to this, the easiest way to mitigate is with process and practice: sandbox code goes into a dedicated "Sandbox" mono-repo and if it's suitable for production, you rebuild it appropriately in a production repo.

Exactly. That's why I don't build the toy anymore: Too many broken promises of "Yes, we won't put it into production until it's ready", and then my team is left maintaining a system in production that had no business of ever being in production.

Maybe they should take one of their courses.

Reply on news.ycombinator.com