3 ms·

Price is a bad reason to outsource it just shifts cost from developer headcount to management headcount. There are two really, really good reasons to consider o

Price is a bad reason to outsource it just shifts cost from developer headcount to management headcount. There are two really, really good reasons to consider offshore outsourcing: * Hire the best. Not every great dev is from North America. There is fantastic talent out there, and you can hire them. Now that most dev teams are used to working remote, it's not nearly as difficult to hire great developers in other parts of the world. * 24 hour development cycle. Teams can operate 6-12 hours offset, and you can go faster. This only works if the offshore team is as good at what they do as the home team.

ehnto 4y ago
Have you experienced real benefits from a 24 hour cycle? I've worked in environments like that and I feel like you're not actually gaining anything except a new layer of asynchronous communication requirements. It's not like you get more man hours after all.
- indymike 4y ago
  Yep. Twice. Once for a big job ad scraping operation (we did this for ofccp compliance) where 24 hour dev enabled our scraping to not miss when our competitors would take 24-48 hours to re-tool when a targeted site changed. The second time was a webdev agency where we routinely were able to win business and delivery by promising to be done in 1/2 the calendar days as our competitors on the same bids. In the second situation I wouldn't have been able to hire enough people locally to just double the local man-hours anyway (small midwest town).
  - addicted 4y ago
    The first one is clearly a situation tailor made for 24/7 because your requirements change in such short periods. This is similar to how companies that offer 24/7 technical support benefit from 24/7 dev availability. The second doesn’t seem to be an advantage for 24/7 availability. You would have achieved the same if you had hired the second team in a different country but in the same time zone as you. Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier.
    - indymike 4y ago
      > Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier. What really worked was building something, showing the customer at 3pm, getting a change list and having all the changes done by 9am the next day. Also being able to do a design session and have all the prototype views done the next day really made customers happy. Another thing that was nice: we could have a bunch of stuff built at night and then test and fix it the next day (or vice versa). You do have to assign tickets a little differently. You want avoid making tickets so big that a developer can't finish one in a day - or you can get into where there's lots of blocking. Regardless, I think the 24 hour cycle worked pretty well for us, and if I start another dev shop, I'll do it that way again. A lot of the benefit was probably forcing everyone to do a couple of smart things: great CI, smaller tickets and complete work in one work day whenever possible. No dangling tickets. Avoid even having tickets where a developer can block another as much as you reasonably can. All of these things would have made a single timezone team better, too.
tharkun__ 4y ago
This means you get 3 teams working on the same thing one after the others. This isn't factory work where that is actually possible, where you know that piece A will get done in exactly 8 hours by Team A, everyone on Team B knows how to make thing B from piece A and 8 hours later Team C makes finished product C from that. You'll get bogged down in communications overhead, things not being done exactly at the time you'd need it, then you gotta do something else or do it yourself etc. Basically there's not a real benefit to 24h operations for software development. Now for 24/7 production support that's great on the other hand, because nobody has to wake up in the middle of the night. I think worldwide teams are actually harder to bootstrap because while sitting right next to each other is overrated in my book, being in similar timezones is hugely beneficial for normal teams. Many people can not work completely async properly and benefit from overlap where they can interact directly. Depending on who you're able to hire this won't be a problem but we're not all able to hire those awesome people or enough of them. So in that case, let's assume you're in the US, east or west coast doesn't matter that much but it would be much better to hire one more person in a similar timezone, say in Brazil that has overlap with you than to get one guy in Turkey where you're offset by an entire 'work day' and he's the only guy in that timezone. That shifts, if you can bootstrap an entire team in that other location. But make them work on a separate product or service, not on the exact same thing the other team you already have does and expect them to throw stuff over the fence back and forth every day. EDIT: And you should expect them to deliver the same quality as other teams. Quality they can stand by. I.e. the exact opposite of what Indian or Eastern European outsourcing usually is. And then, when you have a team that can actually deliver properly like that, you're actually not paying that much less but now all your business people are still over in the US and can't communicate properly with those teams.
ransom1538 4y ago
"24 hour development cycle." Boom. This. is. the. future. International teams i have worked on run circles around the 8-5 crowd. The async affect of forking off a feature at night and getting in depth progress by the am is amazing. It doesn't even matter if the people in Asia or central europe finish, but by the am, there is a working prototype. When they are sleeping we are analyzing the ui/behavior/analytics points - when they awake we have all those things ironed out. If needed we can do a sync of blockers all together. If they need answers, people on the east cost or in england can quickly answer. It is pretty neat to see it work - but the team needs to be quick to react, quick to respond, quick to prototype, quick to trash things that don't work. It is a culture. I don't think this will work at most companies, most do, blocker crash, wait cycles.

ehnto 4y ago

Have you experienced real benefits from a 24 hour cycle? I've worked in environments like that and I feel like you're not actually gaining anything except a new layer of asynchronous communication requirements. It's not like you get more man hours after all.

indymike 4y ago
Yep. Twice. Once for a big job ad scraping operation (we did this for ofccp compliance) where 24 hour dev enabled our scraping to not miss when our competitors would take 24-48 hours to re-tool when a targeted site changed. The second time was a webdev agency where we routinely were able to win business and delivery by promising to be done in 1/2 the calendar days as our competitors on the same bids. In the second situation I wouldn't have been able to hire enough people locally to just double the local man-hours anyway (small midwest town).
- addicted 4y ago
  The first one is clearly a situation tailor made for 24/7 because your requirements change in such short periods. This is similar to how companies that offer 24/7 technical support benefit from 24/7 dev availability. The second doesn’t seem to be an advantage for 24/7 availability. You would have achieved the same if you had hired the second team in a different country but in the same time zone as you. Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier.
  - indymike 4y ago
    > Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier. What really worked was building something, showing the customer at 3pm, getting a change list and having all the changes done by 9am the next day. Also being able to do a design session and have all the prototype views done the next day really made customers happy. Another thing that was nice: we could have a bunch of stuff built at night and then test and fix it the next day (or vice versa). You do have to assign tickets a little differently. You want avoid making tickets so big that a developer can't finish one in a day - or you can get into where there's lots of blocking. Regardless, I think the 24 hour cycle worked pretty well for us, and if I start another dev shop, I'll do it that way again. A lot of the benefit was probably forcing everyone to do a couple of smart things: great CI, smaller tickets and complete work in one work day whenever possible. No dangling tickets. Avoid even having tickets where a developer can block another as much as you reasonably can. All of these things would have made a single timezone team better, too.

tharkun__ 4y ago

This means you get 3 teams working on the same thing one after the others. This isn't factory work where that is actually possible, where you know that piece A will get done in exactly 8 hours by Team A, everyone on Team B knows how to make thing B from piece A and 8 hours later Team C makes finished product C from that. You'll get bogged down in communications overhead, things not being done exactly at the time you'd need it, then you gotta do something else or do it yourself etc. Basically there's not a real benefit to 24h operations for software development. Now for 24/7 production support that's great on the other hand, because nobody has to wake up in the middle of the night. I think worldwide teams are actually harder to bootstrap because while sitting right next to each other is overrated in my book, being in similar timezones is hugely beneficial for normal teams. Many people can not work completely async properly and benefit from overlap where they can interact directly. Depending on who you're able to hire this won't be a problem but we're not all able to hire those awesome people or enough of them. So in that case, let's assume you're in the US, east or west coast doesn't matter that much but it would be much better to hire one more person in a similar timezone, say in Brazil that has overlap with you than to get one guy in Turkey where you're offset by an entire 'work day' and he's the only guy in that timezone. That shifts, if you can bootstrap an entire team in that other location. But make them work on a separate product or service, not on the exact same thing the other team you already have does and expect them to throw stuff over the fence back and forth every day. EDIT: And you should expect them to deliver the same quality as other teams. Quality they can stand by. I.e. the exact opposite of what Indian or Eastern European outsourcing usually is. And then, when you have a team that can actually deliver properly like that, you're actually not paying that much less but now all your business people are still over in the US and can't communicate properly with those teams.

ransom1538 4y ago

"24 hour development cycle." Boom. This. is. the. future. International teams i have worked on run circles around the 8-5 crowd. The async affect of forking off a feature at night and getting in depth progress by the am is amazing. It doesn't even matter if the people in Asia or central europe finish, but by the am, there is a working prototype. When they are sleeping we are analyzing the ui/behavior/analytics points - when they awake we have all those things ironed out. If needed we can do a sync of blockers all together. If they need answers, people on the east cost or in england can quickly answer. It is pretty neat to see it work - but the team needs to be quick to react, quick to respond, quick to prototype, quick to trash things that don't work. It is a culture. I don't think this will work at most companies, most do, blocker crash, wait cycles.