Fast, Right, Cheap. Pick Flexible?
-
I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive. The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months. While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts. Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?
Console.WriteLine("Scott Clayton");
Define "better". "Better" should always include a target, "better for X". And if X is flexibility, then you indeed won't find anything better than hiring a cheap code sweatshop.
-
I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive. The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months. While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts. Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?
Console.WriteLine("Scott Clayton");
I started saying this in the early 2000's... The first 5 years or so of offshoring, you're losing money. The next 5 years or so, you're breaking even(ish), but you're still behind because of the loss the first few years. By the end of the third five-year period, you're finally money ahead... but now you have no corporate knowledge, the people who've gained experience at your expense now want MORE money (so much that you consider on-shoring the work again), your support hours are often offset significantly or nearly 100% from your work hours, and... no local developers want to work for your company because they've seen what you did with your developers. Your only bet will be to onshore the work through contractors or new companies. 15 years later, I'm seeing my prediction come true... and companies are suffering, badly, as a result. It's got ZERO to do with flexibility, and everything to do with the appearance of saving money. I saw it happen, directly, at SunGard Availability Services, EMC, and Dell. I'm sure it's happening elsewhere, too. Decent managers will see it happening and wil have made the business case to retain onshore devs, in whole or in part, and it'll save those companies a mountain of cash in the long run.
-
I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive. The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months. While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts. Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?
Console.WriteLine("Scott Clayton");
Nothing changes until management realizes the approach is wrong. Fully and completely wrong. If the offshoring team is, say, 10 people, I can hire 5 American developers who meet my higher standards, and as a team, we will provide better quality in a shorter time frame. Quality that includes flexibility, speed, and efficacy, and delivers the end product for a lower lifecycle cost. Been there, done that. And not just I, but any knowledgeable, experienced software engineer/architect with good leadership and business skills who has had experience managing quality software development teams.
-
I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive. The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months. While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts. Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?
Console.WriteLine("Scott Clayton");
I will take a different tact... Change your organization by changing HOW you send work to reduce the error rate. I work with a set team of offshored people. Same people for 10+yrs... Love it. One has been with us for like 18+ years... The issues with turnover and ramp up, is because management FALSELY assumes Men and Months are interchangeable. They are not. But do what you can so that EVERYTHING they deliver is better, and gets better. Push all the unit testing over there. Use tools that make sure things are happening. Review the code being checked in. My first response is to SLOW THEM DOWN, while raising their quality. Then work the system so the time shift works to an advantage. This can be quite a valuable skillset to develop. there are bigger companies facing similar problems. As someone wrote... You are learning what 90% of the companies I feel have learned. It sounds good on paper! Make a list of the top 10 things you would like to fix, GIVEN the environment is what it is. Indicate the cost of not fixing those things. Identify the low hanging fruit, and knock it out. Any non-trivial process can be improved. And I would improve it so that your time is not wasted testing "crap" that doesn't work. As an example, VERY EARLY ON, I explained to the first offshore guy that THIS is the formula he should see in his head for getting PAID: ((Hours Spent)*(Hourly Rate)) / (Number of times it took you to get it right)^2 the anticipation is you will spend more time getting it right the first time. After that, your valuable drops of SO QUICKLY that you should not be getting paid much. That forced us to change our front-end process to eradicate errors in the communication process. To encourage questions, while forging ahead one what he could forge ahead on. To reduce deliveries to STABLE/SOLID/TESTED only! (I aint got time to test your code, I want to see it run). You have a basket of Lemons... Be flexible, make Lemonade, Leomon and Vodka, Lemon Martinis, and have some fun!
-
I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive. The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months. While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts. Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?
Console.WriteLine("Scott Clayton");
It's the modern equivalent of building a pyramid; turnover is not an issue. It was the plan all along: the "priests" do the planning; the actual work is left for someone else.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I started saying this in the early 2000's... The first 5 years or so of offshoring, you're losing money. The next 5 years or so, you're breaking even(ish), but you're still behind because of the loss the first few years. By the end of the third five-year period, you're finally money ahead... but now you have no corporate knowledge, the people who've gained experience at your expense now want MORE money (so much that you consider on-shoring the work again), your support hours are often offset significantly or nearly 100% from your work hours, and... no local developers want to work for your company because they've seen what you did with your developers. Your only bet will be to onshore the work through contractors or new companies. 15 years later, I'm seeing my prediction come true... and companies are suffering, badly, as a result. It's got ZERO to do with flexibility, and everything to do with the appearance of saving money. I saw it happen, directly, at SunGard Availability Services, EMC, and Dell. I'm sure it's happening elsewhere, too. Decent managers will see it happening and wil have made the business case to retain onshore devs, in whole or in part, and it'll save those companies a mountain of cash in the long run.
Member 12009066 wrote:
It's got ZERO to do with flexibility, and everything to do with the appearance of saving money.
That's a good point. While to me they may sell it as optimizing flexibility, to the higher-ups it might be sold as being more cost effective. Recently our senior leadership asked for feedback from the department as a whole, and the most popular suggestions included less outsourcing and fundamentally changing our budgeting model. The feedback seems to have been somehow interpreted as "we need more devops and more agile training."
Console.WriteLine("Scott Clayton");
-
I will take a different tact... Change your organization by changing HOW you send work to reduce the error rate. I work with a set team of offshored people. Same people for 10+yrs... Love it. One has been with us for like 18+ years... The issues with turnover and ramp up, is because management FALSELY assumes Men and Months are interchangeable. They are not. But do what you can so that EVERYTHING they deliver is better, and gets better. Push all the unit testing over there. Use tools that make sure things are happening. Review the code being checked in. My first response is to SLOW THEM DOWN, while raising their quality. Then work the system so the time shift works to an advantage. This can be quite a valuable skillset to develop. there are bigger companies facing similar problems. As someone wrote... You are learning what 90% of the companies I feel have learned. It sounds good on paper! Make a list of the top 10 things you would like to fix, GIVEN the environment is what it is. Indicate the cost of not fixing those things. Identify the low hanging fruit, and knock it out. Any non-trivial process can be improved. And I would improve it so that your time is not wasted testing "crap" that doesn't work. As an example, VERY EARLY ON, I explained to the first offshore guy that THIS is the formula he should see in his head for getting PAID: ((Hours Spent)*(Hourly Rate)) / (Number of times it took you to get it right)^2 the anticipation is you will spend more time getting it right the first time. After that, your valuable drops of SO QUICKLY that you should not be getting paid much. That forced us to change our front-end process to eradicate errors in the communication process. To encourage questions, while forging ahead one what he could forge ahead on. To reduce deliveries to STABLE/SOLID/TESTED only! (I aint got time to test your code, I want to see it run). You have a basket of Lemons... Be flexible, make Lemonade, Leomon and Vodka, Lemon Martinis, and have some fun!
Thank you, this is extremely valuable. I can complain all day about how it's not working, but until I can propose a superior alternative, it won't amount to anything. If I'm understanding correctly, the goal is to work on building the offshore team and any communication patterns, processes and expectations to the point where they're delivering stable, quality increments. I've recently requested tools or training for offshore developers only to be told that the offshore company is contractually responsible for training their own developers. That makes it very difficult to explain how, for instance, I expect unit tests to be written. That still leaves a few problems such as suddenly losing someone with domain knowledge just because a project lost funding. Unfortunately that's out of my control. One of our offshore teams has fluctuated from 3 to 1 and up to 5 developers within the last year. Since realistically it's unlikely that they'll stop outsourcing development work, I'll try approaching this from the angle of building a more stable offshore team that can learn our systems and technologies over the long term without getting moved around. Maybe they won't let me build an onshore team, but they may be open to helping me maintain a consistent offshore one.
Console.WriteLine("Scott Clayton");
-
Thank you, this is extremely valuable. I can complain all day about how it's not working, but until I can propose a superior alternative, it won't amount to anything. If I'm understanding correctly, the goal is to work on building the offshore team and any communication patterns, processes and expectations to the point where they're delivering stable, quality increments. I've recently requested tools or training for offshore developers only to be told that the offshore company is contractually responsible for training their own developers. That makes it very difficult to explain how, for instance, I expect unit tests to be written. That still leaves a few problems such as suddenly losing someone with domain knowledge just because a project lost funding. Unfortunately that's out of my control. One of our offshore teams has fluctuated from 3 to 1 and up to 5 developers within the last year. Since realistically it's unlikely that they'll stop outsourcing development work, I'll try approaching this from the angle of building a more stable offshore team that can learn our systems and technologies over the long term without getting moved around. Maybe they won't let me build an onshore team, but they may be open to helping me maintain a consistent offshore one.
Console.WriteLine("Scott Clayton");
Scott, You are clearly moving in the right direction now... Work with what you are given. For example, you mention "tools" that you cannot get them to buy. Okay, you have to be like NASA. You have a capsule in space. YOU start with their inventory of what they have. - People: Quite Variable - Tools: Probably fixed, but you should know them! - Process: You should know this - Communication Strengths and Weaknesses (BTW, Read Malcolm Gladwell on the power index of language. I am lucky, Russian has a pretty high power index, like English. But the Indian culture has a lower power index (Meaning they tend to never say NO, but give a weak yes, which means no!)) - A list of problems you would like to get rid of - A list of skills/techniques to take advantage of Now, solve the problems with the available resources. Make it iterative. The single biggest thing I did was to point out that THEY HAVE ZERO VALUE if they waste time. Programmers will make "weird decisions" like "I need to prompt for something, but EVERYONE KNOWS its in Kg/m^2, so I wont mention the units." Sometimes because it might take them a few extra minutes. And the negative impact of those types of decisions are catastrophic over time. If I were in your shoes, I would push for: - Strong Coding Standards, and tools to help make sure all checked in code fits - Strong Testing Standards/Processes. Keeping in mind, in other countries it is cheaper to use humans, than to use tools. - A Checklist of things they have to do before they publish - Clearly a hierarchy of Development, Staging, and Production - Regression (Any bug found must be tested for in the future) - Delineation between Critical/Complex systems (High Risk to change), and easy to change/low-risk areas - REGULAR After Action Reviews (Post-Mortems), I have an article about these. Do more of the good, less of the bad. Work the process. Get it cleaned up. And make sure that the tools are properly configured for THEIR environment. Maybe the BUILD/MAKE Process has to start with a PREAMBLE and END with text about what they MUST DO before they commit. Eventually, say in 6 months. Your process should stabilize. Their quality should go up BECAUSE of fewer hiccups! The time spent communicating and the quality of the communication should be increasing. Then, push to add ONE developer locally. Maybe to manage the critical stuff. Maybe to make the UI/UX changes that are cultural, and would eliminate the need for a 2 day turnaround. Managem
-
Scott, You are clearly moving in the right direction now... Work with what you are given. For example, you mention "tools" that you cannot get them to buy. Okay, you have to be like NASA. You have a capsule in space. YOU start with their inventory of what they have. - People: Quite Variable - Tools: Probably fixed, but you should know them! - Process: You should know this - Communication Strengths and Weaknesses (BTW, Read Malcolm Gladwell on the power index of language. I am lucky, Russian has a pretty high power index, like English. But the Indian culture has a lower power index (Meaning they tend to never say NO, but give a weak yes, which means no!)) - A list of problems you would like to get rid of - A list of skills/techniques to take advantage of Now, solve the problems with the available resources. Make it iterative. The single biggest thing I did was to point out that THEY HAVE ZERO VALUE if they waste time. Programmers will make "weird decisions" like "I need to prompt for something, but EVERYONE KNOWS its in Kg/m^2, so I wont mention the units." Sometimes because it might take them a few extra minutes. And the negative impact of those types of decisions are catastrophic over time. If I were in your shoes, I would push for: - Strong Coding Standards, and tools to help make sure all checked in code fits - Strong Testing Standards/Processes. Keeping in mind, in other countries it is cheaper to use humans, than to use tools. - A Checklist of things they have to do before they publish - Clearly a hierarchy of Development, Staging, and Production - Regression (Any bug found must be tested for in the future) - Delineation between Critical/Complex systems (High Risk to change), and easy to change/low-risk areas - REGULAR After Action Reviews (Post-Mortems), I have an article about these. Do more of the good, less of the bad. Work the process. Get it cleaned up. And make sure that the tools are properly configured for THEIR environment. Maybe the BUILD/MAKE Process has to start with a PREAMBLE and END with text about what they MUST DO before they commit. Eventually, say in 6 months. Your process should stabilize. Their quality should go up BECAUSE of fewer hiccups! The time spent communicating and the quality of the communication should be increasing. Then, push to add ONE developer locally. Maybe to manage the critical stuff. Maybe to make the UI/UX changes that are cultural, and would eliminate the need for a 2 day turnaround. Managem
Yes, this is definitely helpful. I'll have take a look at that book on the power indexes of languages. Just recently some stuff didn't get done because I understood "yes" to mean yes. Learning cultural differences, especially as they apply to communication, is important. If I'm honest, I've been slacking on reviewing code recently. Sometimes I give up because I'm strapped for time or because I've already sent it back a few times. Our release pipeline is decently robust. Pull requests automatically trigger a build and run unit tests. Releases themselves are scripted and require just a few approvals in TFS Release Manager. Takeaways: - Document standards, processes, and expectations - Focus on enforcing quality - Include offshore in postmortems - Stop blaming contractors And by the way, I seriously plan to make this work. This isn't an academic exercise or venue to rant. I really want to fix this up. Thanks again!
Console.WriteLine("Scott Clayton");
-
Yes, this is definitely helpful. I'll have take a look at that book on the power indexes of languages. Just recently some stuff didn't get done because I understood "yes" to mean yes. Learning cultural differences, especially as they apply to communication, is important. If I'm honest, I've been slacking on reviewing code recently. Sometimes I give up because I'm strapped for time or because I've already sent it back a few times. Our release pipeline is decently robust. Pull requests automatically trigger a build and run unit tests. Releases themselves are scripted and require just a few approvals in TFS Release Manager. Takeaways: - Document standards, processes, and expectations - Focus on enforcing quality - Include offshore in postmortems - Stop blaming contractors And by the way, I seriously plan to make this work. This isn't an academic exercise or venue to rant. I really want to fix this up. Thanks again!
Console.WriteLine("Scott Clayton");
Scott, I am glad I could help. DM me if you need any help if you run into specific hurdles. But usually once you adjust your mindset, the solutions present themselves. Also, handle it iteratively. It will NEVER be perfect, but it can always be better.