this post was submitted on 04 May 2024
255 points (98.9% liked)

Games

16696 readers
972 users here now

Video game news oriented community. No NanoUFO is not a bot :)

Posts.

  1. News oriented content (general reviews, previews or retrospectives allowed).
  2. Broad discussion posts (preferably not only about a specific game).
  3. No humor/memes etc..
  4. No affiliate links
  5. No advertising.
  6. No clickbait, editorialized, sensational titles. State the game in question in the title. No all caps.
  7. No self promotion.
  8. No duplicate posts, newer post will be deleted unless there is more discussion in one of the posts.
  9. No politics.

Comments.

  1. No personal attacks.
  2. Obey instance rules.
  3. No low effort comments(one or two words, emoji etc..)
  4. Please use spoiler tags for spoilers.

My goal is just to have a community where people can go and see what new game news is out for the day and comment on it.

Other communities:

Beehaw.org gaming

Lemmy.ml gaming

lemmy.ca pcgaming

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] ricecake@sh.itjust.works 6 points 6 months ago

The only way hiring people will help you develop faster is if either:

  • ramp up time is insignificant compared to project time and you don't hire so many you hit communication overhead.
  • you're hiring people to do all the other stuff the people working on the project were also doing. I don't think game devs typically have four systems in the maintenance lifecycle while they also develop new stuff, so that means you're hiring a few IT folks to wrangle the weird office issues programmers wander off and deal with, a sysadmin, and like, 45 lunch delivery people.

I've had the first one work once, when we had a year+ project timeline. Hired one person, took them a week to get started, a month to be properly contributing and maybe another to be up to speed. We were a four person team, so not much overhead.
The second one is the dream of every manager who finds themselves with a contractor budget. I have yet to see it work the way they want. The only way I've seen it work is when you tell an established team that some other teams maintenance project is now their maintenance project, and eat the sharp increase in timelines for that maintenance work.