Honestly, most dev effort at big companies goes into ensuring nothing breaks or slows performance. When news articles are written about your mistakes, most developers and managers try not to break things.
Making new stuff happens, but it just can’t happen as fast as at small companies where 90% uptime is good enough.
That said, it doesn’t excuse launching products half baked. No reason an unlaunched product can’t be iterated on quickly during dev.
No reason? It’s probably meetings, then more meetings, add some meetings, and you guessed it, meetings.
Like the follow tab mentioned it’s probably first product owners meetings to agree on what a user would expect… and there’s always someone having a wild opinion or two that needs to be “hashed out”. Then when that’s done it’s meetings with the UX team, then they have a meeting on their own, then a new meeting with product owner, UX and designers, then after that frontend team is in the loop, then back to UX and prod owner, then a new round, then it’s time for backend to come in, first one with PO and frontend, then a technical one to agree on how to do it, then database team is involved, they refuse to change a small thing and expected functionality needs to be changed, back to PO, UX, frontend, backend, and then finally maybe a dev or two can sit down and add it. Which takes 2 hours. After six weeks of meetings.
And then comes testing of course, and signoff on the functionality.
Totally agree about the amount of coordination overhead. That is a huge amount of time to do anything.
But even so, it’s even slower, by a lot, once you pull the ripcord and need to keep the site working while you update it.
Prior to release you don’t need to have branch and release then QA then deploy. You can just modify schemas and drop existing user data without needing to migrate anything. You can change the look of the interface without angering users who generally hate change.
Just the cycle of releasing new features carefully is a ton of overhead.
I’ve spent entire days just rolling out code to change which domain name is used to refer to some images because doing it quickly would overwhelm the image servers due to the caches being unpopulated. 100% of that would be unnecessary prior to going live.
Honestly, most dev effort at big companies goes into ensuring nothing breaks or slows performance. When news articles are written about your mistakes, most developers and managers try not to break things.
Making new stuff happens, but it just can’t happen as fast as at small companies where 90% uptime is good enough.
That said, it doesn’t excuse launching products half baked. No reason an unlaunched product can’t be iterated on quickly during dev.
No reason? It’s probably meetings, then more meetings, add some meetings, and you guessed it, meetings.
Like the follow tab mentioned it’s probably first product owners meetings to agree on what a user would expect… and there’s always someone having a wild opinion or two that needs to be “hashed out”. Then when that’s done it’s meetings with the UX team, then they have a meeting on their own, then a new meeting with product owner, UX and designers, then after that frontend team is in the loop, then back to UX and prod owner, then a new round, then it’s time for backend to come in, first one with PO and frontend, then a technical one to agree on how to do it, then database team is involved, they refuse to change a small thing and expected functionality needs to be changed, back to PO, UX, frontend, backend, and then finally maybe a dev or two can sit down and add it. Which takes 2 hours. After six weeks of meetings.
And then comes testing of course, and signoff on the functionality.
“Fast” is nowhere in enterprise development.
Totally agree about the amount of coordination overhead. That is a huge amount of time to do anything.
But even so, it’s even slower, by a lot, once you pull the ripcord and need to keep the site working while you update it.
Prior to release you don’t need to have branch and release then QA then deploy. You can just modify schemas and drop existing user data without needing to migrate anything. You can change the look of the interface without angering users who generally hate change.
Just the cycle of releasing new features carefully is a ton of overhead.
I’ve spent entire days just rolling out code to change which domain name is used to refer to some images because doing it quickly would overwhelm the image servers due to the caches being unpopulated. 100% of that would be unnecessary prior to going live.