3 ms·

You may be joking, but this is already how my team has been operating for the past 6 months. Theoretically it sounds great, because you can scale up or down you

You may be joking, but this is already how my team has been operating for the past 6 months. Theoretically it sounds great, because you can scale up or down your engineering needs just like you scale anything on the cloud. Have 100 Github issues to fix this week? Scale up to 20 freelance devs for a week and get it done. Practically, it doesn't work. We're going to go back to hiring full-time engineers again.

thebiglebrewski 6y ago
Why doesn't it work? Genuinely curious!
- marcinzm 6y ago
  I'd guess because: * It takes months for an engineer to be properly ramped up on a new codebase and even longer for business domain expertise. Until then they might actually be negatively productive due to onboarding questions other devs must answer. * Enforcing any coding standards is difficult so you get a lot of technical debt over time. edit: Also, a good engineer on a well functioning team will push back on bad or inefficient feature requirements. If you're just getting paid by feature and feel no ownership of the product then you have little incentive to do that.
  - bitbuilder 6y ago
    I'd add to that, team dynamics can't be discounted. Feeling part of a team is good for morale, and in turn productivity. People tend to produce better work, on a faster timeline, when the respect of their teammates is on the line. Also, with any given team and codebase, team members will tend to carve out unofficial roles that best fit their abilities. This of course increases the net productivity of the team.
- easton 6y ago
  You'd run into Brooks's law pretty quickly, that is, "adding manpower to a late software project makes it later", since you have to spend a bunch of the current engineers' time to get the new people up to speed. Especially for one issue, which maybe doesn't require a lot of domain knowledge, but being neck deep you sometimes can't estimate that properly. https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law

thebiglebrewski 6y ago

Why doesn't it work? Genuinely curious!

marcinzm 6y ago
I'd guess because: * It takes months for an engineer to be properly ramped up on a new codebase and even longer for business domain expertise. Until then they might actually be negatively productive due to onboarding questions other devs must answer. * Enforcing any coding standards is difficult so you get a lot of technical debt over time. edit: Also, a good engineer on a well functioning team will push back on bad or inefficient feature requirements. If you're just getting paid by feature and feel no ownership of the product then you have little incentive to do that.
- bitbuilder 6y ago
  I'd add to that, team dynamics can't be discounted. Feeling part of a team is good for morale, and in turn productivity. People tend to produce better work, on a faster timeline, when the respect of their teammates is on the line. Also, with any given team and codebase, team members will tend to carve out unofficial roles that best fit their abilities. This of course increases the net productivity of the team.
easton 6y ago
You'd run into Brooks's law pretty quickly, that is, "adding manpower to a late software project makes it later", since you have to spend a bunch of the current engineers' time to get the new people up to speed. Especially for one issue, which maybe doesn't require a lot of domain knowledge, but being neck deep you sometimes can't estimate that properly. https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law