> Creating a new backend endpoint requires a multi-week design review process and must be implemented in a straight-jacket of a programming language with 90% test coverage and tons of layers and extensive mocks of each layer.
Or perhaps an hour or so long meeting, in which the overall design is discussed so everyone is vaguely on the same page and the rest is handled when reviewing the merge request and/or as Slack messages in the appropriate channels, as necessary. Heck, shoot a message to the business analysts and maybe have a 5-10 minute conversation to clear up any of the stuff that you don't understand.
> Creating a new frontend requires the same multi-week design review process, and must use the Nth incarnation of our NIH Javascript framework. The developer who built it got promoted and then left; it's been handed over to India to maintain. So anytime anything goes wrong, post a question to the framework maintainer's slack channel and wait to hear back in the morning. Or don't. They're just as mystified by it as you are.
Or use the exact same approach as above, with whatever was used in the other components of the system, for familiarity's sake. Some vaguely recent version of Vue? Sure, go ahead! Maybe even copy some bits that don't feel like they should be shared code and could change in the future, but that'll be easy to reuse for now.
> Creating new external APIs requires, ironically, no design review but you must use the shitty homegrown code generation tool to generate a PR to add your endpoints to the API gateway. The builds on this PR take 4 hours. Then after it's merged you can wait for the API gateway to be deployed later this week. You must repeat this process any time the schema changes.
Quite on the contrary - it's just an API that perhaps needs a bit more attention from the security specialists and some additional scanning here and there. Knock it out, give it to others to test and fix any of the problems that they find. Builds might take around 5-15 minutes.
> Creating a new RDBMS table goes through a theoretically self-service workflow hosted by the RDBMS team but probably one step fails so you need to file a ticket and wait for them to fix it before your table is provisioned and ACLs dialed in.
Or, you know, are integrated as a migration file within the application, that will automatically get applied to the testing/staging/prod databases when the changes land in the environment. Maybe even use a local DB instance for breaking changes inside of a Docker container, so that you can discard any of the stuff that you break.
> In-house object storage implements an S3 compatible API but you must submit a ticket with a detailed description of your use case and wait a week or two to get provisioned.
Or just add whatever software you need to a Docker Swarm + Ansible deployment on your company's servers and have it be up there in a matter of minutes. Maybe grab a coffee, because rerunning parts of Ansible playbooks is sometimes a bit hard, but procrastinating for 10 minutes never hurt anyone. Then test whether everything works in your development environments and let the people responsible for accept testing, security and prod deployments handle the rest.
> If your email is static or contains only simple account properties, it's easy to create in the internal email platform's template builder UI. But if it needs complex data from your application, you'll need to land changes against the email platform to implement fetching of that data from your application. No, you can't push data into the template from the sending application, that would be too easy.
Or just add a new Java class and some templating logic to generate whatever you need in the application code.
> Compare to one or a few people working directly with Django/Rails, React, S3, Postmark, etc. and practicing the "write tests, not too many, mostly integration" thing.
And possibly end up with an insecure, faulty and otherwise unmaintainable solution because there wasn't even a modicum of oversight, or alternatively don't ship anything in a timely manner because the scope creep was unmanageable for the amount of people that you had. Or maybe just end up with those people using SaaS solutions which are more like SaaSS ( https://www.gnu.org/philosophy/who-does-that-server-really-s... ) which you were legally not allowed to do due to where the data ends up and then have bunches of fun dealing with the legal implications of that.
Bottom line: if most of your time is spent fighting corporate policies and bureaucratic apparatus, it doesn't really matter whether you have 1, 5 or 10 people on your team, because dysfunctional environments can happen at any scale. I'd say that what you describe is an environment that's actively hostile to getting anything done, which could stem from a lack of decent management and people doing whatever they can to make themselves look better for a performance review, or to justify their own existence. Having too many people would definitely contribute to that, but at this point i feel like this discussion has perhaps devolved into some parody of the Goldilocks story, where the corporation would struggle to find the right amount of people.
Furthermore, i guess it's a matter of attempting to centralize everything vs having a decentralized approach, seeing as different projects and teams might need different solutions, hopefully mostly open source ones. I do think that you're perhaps also bringing up the fact that larger corporations oftentimes attempt to standardize on this stuff, much to everyone's chagrin, but that's not necessarily caused by the team size alone, rather the point in the company's lifecycle.
I should know - i've seen both of the scenarios above and having few focused people can indeed work nicely! For example, i developed the homepage for the contact tracing application in my country alone, a page that saw hundreds of thousands of visitors: https://apturicovid.lv/#en Due to that trust placed in me and the creative freedom, i was able to deliver about 70 different deployments of the site as well over a few months.
Did it work nicely? Yes. Was there also a pretty big possibility of me messing up? Also yes. Would this approach work for startups, side hustles and other smaller projects? Sure. Would i want to do the same for your typical enterprise project where battling scope creep and shifting priorities is the everyday reality, whilst the concept of set sprints is a joke? Probably not, that's where having more people makes sense.