4 ms·

We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cat

We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads.

intelVISA 3y ago
The hardest thing, as noted by others, is managing the auxillary complexity -- which is often introduced by excess, sometimes underskilled, developers. The 'good' (whatever that means) devs will waste more of their time hacking around the above... so more devs are added to compensate... repeat a few times: Fred's prophecy becomes manifest.
rqtwteye 3y ago
I struggle with that all the time. We have a lot of offshore people and I am pretty sure that 3 experienced people could take on a project that requires 50 offshore people and get it done in less time at higher quality.
- Clubber 3y ago
  I struggled with this a lot too. I came to the conclusion that an offshore developer who as good as a good onshore developer costs about the same, just due to supply and demand, so it's a wash. If a company can't find or retain talent, hiring a not great developer offshore is cheaper than hiring a not great developer onshore. It's an "I give up" strategy; you can build the same mediocre, buggy crap cheaper offshore. Plus, off shore sales people are very good and promise the world. Many traditional executives are gullible when it comes to technology, but they're pretty good at turd polishing, so that's also part of it too. I also think OpEx vs CapEx accounting has a lot to do with it as well.
- treeman79 3y ago
  20 years in industry. Typical Offshore people have almost always been a waste of time and just slowed down getting anything useful done. Now, I’ve also hired internationally from all over world and that has usually been fine.
  - tecleandor 3y ago
    Question in good faith, from a non native English speaker... What would be the difference between offshore and hiring internationally?
    - robjan 3y ago
      When you offshore cost is the main factor and the companies optimise for it. As an example you may have an offshoring contract with Infosys where you pay around $20/hour/head and they provide mostly freshgrads (some times referred to as "commodity developers") with dubious qualifications. But you can say you have 100 engineers on the project. When hiring internationally you usually hire and interview a specific person and pay them well through Deel (or equivalent). All of the former engagements have been a disaster, the latter have mostly worked out. Both have their benefits. In my experience offshore teams are basically an army that you need to train and provide a lot of direction. It can be very frustrating but if you have code generators, Sonarqube, linters and they are only working on CRUD applications it sometimes works out. Whereas international hires are usually very competent because you personally selected them.
    - MacsHeadroom 3y ago
      The difference is only implied in their comment. They are using "offshoring" to referring to relying on a completely outside team to deliver a product. In comparison to hiring individuals internationally to work with an internal team. In the first case the entire project is "offshore." In the second case only individual team members are not in the primary country.
    - sdiupIGPWEfh 3y ago
      To me, "offshore" means acquiring developers from international shops that bid for US contracts, whereas hiring internationally just means hiring outside the country on an individual basis. Speaking very broadly here, my impression is that those offshore development shops bidding for US contracts often don't have the greatest working conditions. Those talented enough to know their worth and find better options will do so if the opportunity presents itself, which could mean either applying for international positions on their own or immigrating to where the jobs are. Thus there's an outflow of talent away from those offshore companies.
molsongolden 3y ago
This is a problem across many job functions. It's always faster for "just the pros" to bang out a project or deliverable but it's usually in the company's interest to also be training more pros. Every more junior person on a project is going to be less efficient than a senior person but they need to level up and go through the apprenticeship phases to become a senior person. Very small companies or teams can tactically choose to pay more and only hire top talent but most places will need to develop internal talent due to budget, recruiting, or bus factor (business resiliency) constraints.
- dclowd9901 3y ago
  Why don’t companies have pros make things and non-pros maintain those things after they’re made?
  - deepsun 3y ago
    Reasonable argument, I like it, however would add a bit of salt: I've seen several times so far that people maintaining things are actually doing a much better job, while those who were granted honor of doing a new thing because hey they are "pros". And once they did the prototype, they are _considered_ even more "pros", because hey, they wrote it. The people who rethought and rewrote the thing later were real makers, but didn't get the appreciation of "pros". The worst thing is that "pros" status keeps working for itself, even while delivering worse job. I wouldn't have a problem if the system could fix itself over time. Kinda related: "Confession of a so-called AI expert " https://huyenchip.com/2017/07/28/confession.html https://huyenchip.com/2017/07/28/confession.html
    - withinboredom 3y ago
      I've been on both sides of this fence. As a maintainer, you have all the time in the world to understand the system, as it is, and improve it. You have the benefits of hindsight. As a producer of the mvp, a lot of times there is 'exploratory code' where you're not actually sure how it will work yet; or scale. So you bang out a few approaches and pick the best one for the constraints you have. And basically never touch it again. In one case, I was working on the mvp and the team who would be maintaining it where the one's doing code review. The code turned out way better than either of us would have come up alone. It ended up being one of the coolest projects in the company and some internal secret-sauce for making money. For example, I remember one code review where they asked to add a configurable callback in. I was like 'why?' and they answered, "we're already being asked if it can do X, if you add a callback here, here and here, we can already start building that feature so you can focus on the core."
swader999 3y ago
Ed Yordon I think said you can't make a baby in one month with 9 people. More than six on a team and communication overhead goes through the roof.
- 9659 3y ago
  s/Yordon/Yourdon/ I consider him a giant in software, but because he was "IT Focused" he was not as loved as others.
- serallak 3y ago
  That was Fred Brooks, in "The Mythical Man Month". As relevant today as when it was first published, in 1975.
  - regularfry 3y ago
    And it never ceases to amaze me that people think "dev-day" is any less mythical.
    - swader999 3y ago
      Only quote points.
neilv 3y ago
> We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads. 20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers. Or, if you get people who just want to call themselves a "dev" and grind concrete task assignments in a straightforward way, then I think you either need to be doing something bog-standard and naturally amendable to just going through the motions (e.g., scalable Web CRUD, or yet another forum/chat app), or you need a brilliant approach to structuring the work.
- BigJono 3y ago
  > 20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers. I don't think it makes sense to talk in terms of absolute numbers. It depends on the size of the company and what they're trying to build. It's more like "n good developers are faster than 10*n shit developers". If you have enough essential complexity in what you're selling to your users you could realistically have 50s or 100s of developers where every single one of them is like "startup grade" and has their own projects with their own responsibilites, their own autonomy and low communication overhead. The problem isn't companies that have 200 devs. It's companies that have 2000 devs that could run with 200 (or companies that have 200 devs that could run with 20, or companies with 20 that get outcompeted by 2 people in a garage). I've seen all of them at some point in consulting.

intelVISA 3y ago

The hardest thing, as noted by others, is managing the auxillary complexity -- which is often introduced by excess, sometimes underskilled, developers. The 'good' (whatever that means) devs will waste more of their time hacking around the above... so more devs are added to compensate... repeat a few times: Fred's prophecy becomes manifest.

rqtwteye 3y ago

I struggle with that all the time. We have a lot of offshore people and I am pretty sure that 3 experienced people could take on a project that requires 50 offshore people and get it done in less time at higher quality.

Clubber 3y ago
I struggled with this a lot too. I came to the conclusion that an offshore developer who as good as a good onshore developer costs about the same, just due to supply and demand, so it's a wash. If a company can't find or retain talent, hiring a not great developer offshore is cheaper than hiring a not great developer onshore. It's an "I give up" strategy; you can build the same mediocre, buggy crap cheaper offshore. Plus, off shore sales people are very good and promise the world. Many traditional executives are gullible when it comes to technology, but they're pretty good at turd polishing, so that's also part of it too. I also think OpEx vs CapEx accounting has a lot to do with it as well.
treeman79 3y ago
20 years in industry. Typical Offshore people have almost always been a waste of time and just slowed down getting anything useful done. Now, I’ve also hired internationally from all over world and that has usually been fine.
- tecleandor 3y ago
  Question in good faith, from a non native English speaker... What would be the difference between offshore and hiring internationally?
  - robjan 3y ago
    When you offshore cost is the main factor and the companies optimise for it. As an example you may have an offshoring contract with Infosys where you pay around $20/hour/head and they provide mostly freshgrads (some times referred to as "commodity developers") with dubious qualifications. But you can say you have 100 engineers on the project. When hiring internationally you usually hire and interview a specific person and pay them well through Deel (or equivalent). All of the former engagements have been a disaster, the latter have mostly worked out. Both have their benefits. In my experience offshore teams are basically an army that you need to train and provide a lot of direction. It can be very frustrating but if you have code generators, Sonarqube, linters and they are only working on CRUD applications it sometimes works out. Whereas international hires are usually very competent because you personally selected them.
  - MacsHeadroom 3y ago
    The difference is only implied in their comment. They are using "offshoring" to referring to relying on a completely outside team to deliver a product. In comparison to hiring individuals internationally to work with an internal team. In the first case the entire project is "offshore." In the second case only individual team members are not in the primary country.
  - sdiupIGPWEfh 3y ago
    To me, "offshore" means acquiring developers from international shops that bid for US contracts, whereas hiring internationally just means hiring outside the country on an individual basis. Speaking very broadly here, my impression is that those offshore development shops bidding for US contracts often don't have the greatest working conditions. Those talented enough to know their worth and find better options will do so if the opportunity presents itself, which could mean either applying for international positions on their own or immigrating to where the jobs are. Thus there's an outflow of talent away from those offshore companies.

molsongolden 3y ago

This is a problem across many job functions. It's always faster for "just the pros" to bang out a project or deliverable but it's usually in the company's interest to also be training more pros. Every more junior person on a project is going to be less efficient than a senior person but they need to level up and go through the apprenticeship phases to become a senior person. Very small companies or teams can tactically choose to pay more and only hire top talent but most places will need to develop internal talent due to budget, recruiting, or bus factor (business resiliency) constraints.

dclowd9901 3y ago
Why don’t companies have pros make things and non-pros maintain those things after they’re made?
- deepsun 3y ago
  Reasonable argument, I like it, however would add a bit of salt: I've seen several times so far that people maintaining things are actually doing a much better job, while those who were granted honor of doing a new thing because hey they are "pros". And once they did the prototype, they are _considered_ even more "pros", because hey, they wrote it. The people who rethought and rewrote the thing later were real makers, but didn't get the appreciation of "pros". The worst thing is that "pros" status keeps working for itself, even while delivering worse job. I wouldn't have a problem if the system could fix itself over time. Kinda related: "Confession of a so-called AI expert " https://huyenchip.com/2017/07/28/confession.html https://huyenchip.com/2017/07/28/confession.html
  - withinboredom 3y ago
    I've been on both sides of this fence. As a maintainer, you have all the time in the world to understand the system, as it is, and improve it. You have the benefits of hindsight. As a producer of the mvp, a lot of times there is 'exploratory code' where you're not actually sure how it will work yet; or scale. So you bang out a few approaches and pick the best one for the constraints you have. And basically never touch it again. In one case, I was working on the mvp and the team who would be maintaining it where the one's doing code review. The code turned out way better than either of us would have come up alone. It ended up being one of the coolest projects in the company and some internal secret-sauce for making money. For example, I remember one code review where they asked to add a configurable callback in. I was like 'why?' and they answered, "we're already being asked if it can do X, if you add a callback here, here and here, we can already start building that feature so you can focus on the core."

swader999 3y ago

Ed Yordon I think said you can't make a baby in one month with 9 people. More than six on a team and communication overhead goes through the roof.

9659 3y ago
s/Yordon/Yourdon/ I consider him a giant in software, but because he was "IT Focused" he was not as loved as others.
serallak 3y ago
That was Fred Brooks, in "The Mythical Man Month". As relevant today as when it was first published, in 1975.
- regularfry 3y ago
  And it never ceases to amaze me that people think "dev-day" is any less mythical.
  - swader999 3y ago
    Only quote points.

neilv 3y ago

> We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads. 20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers. Or, if you get people who just want to call themselves a "dev" and grind concrete task assignments in a straightforward way, then I think you either need to be doing something bog-standard and naturally amendable to just going through the motions (e.g., scalable Web CRUD, or yet another forum/chat app), or you need a brilliant approach to structuring the work.

BigJono 3y ago
> 20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers. I don't think it makes sense to talk in terms of absolute numbers. It depends on the size of the company and what they're trying to build. It's more like "n good developers are faster than 10*n shit developers". If you have enough essential complexity in what you're selling to your users you could realistically have 50s or 100s of developers where every single one of them is like "startup grade" and has their own projects with their own responsibilites, their own autonomy and low communication overhead. The problem isn't companies that have 200 devs. It's companies that have 2000 devs that could run with 200 (or companies that have 200 devs that could run with 20, or companies with 20 that get outcompeted by 2 people in a garage). I've seen all of them at some point in consulting.