3 ms·

Iterating can take many forms, and different teams have different workflows. For my work, I would rarely be able to make a "quick prototype" even if I wanted to

Iterating can take many forms, and different teams have different workflows. For my work, I would rarely be able to make a "quick prototype" even if I wanted to, since most of my projects need to modify other people's code. And they have to be deployed to be validated. In those cases you better have some consistent plan that everyone agrees on before anybody else lets you touch code that they are responsible for. Yes, you can still make mistakes and iterate, but you need to plan for those too. But I agree with you if you can prototype with a fresh body of code, not touching shared repositories.

kqr 5y ago
If your quick prototypes as a rule require complex interactions with other team's services, the problem is your architecture. Try to find the smallest step toward an architecture that allows you to prototype in relative isolation. Take that and repeat. Yes, prototypes have to be deployed. That goes for everyone's prototypes. That's how you get feedback on them. If it's a big deal that you have to deploy your prototypes, find the smallest step you can towards deployments that are less of a big deal and take it. Then repeat. Paper engineering is never better than just trying out the thing in the real world. Most engineering professions have transaction costs that make this impossible. We have the ability to lower those transaction costs, if we just make the right effort. Come on, do it! It will be fun. (And "that doesn't work here" has been debunked so many times. It does work also for you.)