this post was submitted on 14 Jul 2023
499 points (96.8% liked)

Technology

59708 readers
5450 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 11 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago

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.