If developers have to commit and wait for a build + test + deploy pipeline to see if their code works, that should be priority #1 to fix.
My experience is that it just isn't prioritized, and you have to do it early to enforce good engineering solutions to keep it this way. It's much easier to keep something locally runnable than try to set it up that way six months into a project.
If you can't run the stack locally, it makes it harder to set up performance and acceptance testing later. Running locally also makes long build times more noticeable and it's easier to address these issues earlier.
Being able to run locally looks low value at first, but if you do it, and sustain it, you get extremely large project-wide benefits later.
my experience as well and it blows my fucking mind every time I see it. It tells me developers have _no clue_ what it is they're doing that is helping or hindering them.
I think a lot of dev shops just genuinely don't realise it can be done.
I've never been in a startup right at the beginning, but I don't understand how a stack would ever be allowed to transition away from being locally-runnable.
We were fine until we started using Snowflake. The SQL doesn’t quite transpile to Postgres, and anyway we’re using some Python functions where the equivalent SQL would be nightmarishly complicated. I hate that we can’t iterate fast on that part of the stack.
Could we build something that works nearly identically, but locally? Yes, but we’d need to submit some patches to sqlglot, which nobody has time for.
Could we avoid using Snowflake altogether? Only with a lot more work. It solves a few real problems for us.
Current project I work on, everyone looked at me like I was made of cheese when I asked how I spin up the project locally. They only do unit and component tests locally, the rest is assumed to work when deployed.
Another killer is no contribution guide as a living doc for the team. "Code reviews" end up being a weird gate-keeping mechanism to exercise your authority over others by pointing out things they haven't done "correctly" when there is no shared consensus on what is correct and why.
So in a way it's "local" because we have private environments to build & test the code (and don't need to go through a build system) but it is still a relatively slow code-compile-test loop.
fun times...
even more fun when that project is a GUI app installed on lots of computers and now you have a new dependency to roll out to every system because it would be too hard for the dev to revert and fix it where the code did not need that dependency...
Even more fun when that dependency comes from licensed software that you only have a limited number of licenses for
You can see the effect in many large SaaS/tech products in the form of latency in the double digits to forever looping redirects of their service to Narnia and back.
You really shouldn't have to do more if the contracts are strong-enough.
If you really are that fragile you have a micro-monolith not micro-services.
If you have to run everything, what is micro? The individual deployable binaries (but their sum is now even bigger...)?!!
Startup time is the main productivity issue in our stack. We load lots of datasets into memory on startup, which can take minutes.