Is Offshore Outsourcing Really Cheaper?

Offshoring software development has become a common practice for many companies, having gained immense popularity over the last 10-15 years. So much so, that in India alone, outsourcing is now a nearly $150 billion industry. Why? It’s simple: offshore labor is much cheaper. But in reality, the hourly rate that you pay is just one factor when it comes to determining the actual cost of offshoring. Read on for four areas of potential hidden cost that may make you think twice about considering an offshoring investment.   Project Management Costs                      A critical component to ensuring a successful outsourcing engagement is the ability to manage the project effectively. Time zone differences, frequent and fast-paced requirement changes, plus the inherent nature of agile software development means additional management and oversight needs can pop up unexpectedly. This leads to the possibility of teams getting stretched too thin while trying to coordinate communication among developers and stakeholders, across multiple time zones. Often, additional management resources must be put in place, which means additional cost. Resource Ramp-Up/Turnover Rates                    Depending on the offshore provider and your ability to command their attention, it may take much longer to ramp up the right resources necessary to meet your requirements. Unless you are a very large enterprise, you may have to wait in line for the best people. Additionally, if you’re working with a smaller or midsize offshore company, retaining top talent can be a problem which causes project delays due to the variability of resources being used on a project. Cultural and Communication Barriers The ability to communicate effectively with your outsourced development team has a direct impact on the timeliness and quality of deliverables. Cultural differences or misunderstandings can also affect how well teams work together, and sometimes cause unnecessary friction. In fact, in some cultures, maintaining positive relationships with clients is so important that in order to avoid any sort of tension, sometimes overseas colleagues will simply say what they think the other person wants to hear, instead of the true state of affairs. This is in stark contrast to the United States, where employees tend to value being straight forward and specific in order to get the job done as efficiently as possible. Additionally, a lack of understanding of how business is conducted in the U.S. or unfamiliarity with regulations can slow processes down. There may be less application of best practices and fewer innovative ideas as a result. Geopolitical Risks Economic, social or political strife can cause additional risks (and costs) when you’re offshoring. We’ve seen trade disputes between the US and China, more stringent H1-B visa restrictions in the U.S., terrorist attacks in Sri Lanka and most recently political tensions in Belarus. In other countries, health crises, ongoing violence and petty crime may make you less inclined to send employees to these areas, reducing important local training and vendor management time, and adding risk to service delivery. While there’s no doubt that the offshore model for software development has been an effective resource for many companies, it may not be the right fit for every organization or for every project. To determine your true cost of offshoring (TCO), use our free TCO calculator to help understand which outsourcing option may work best for your organization. TRY OUR TRUE COST OF OFFSHORING (TCO) CALCULATOR

Our Mission in Action: Jeanne Schmidt

Our guiding force at Rural Sourcing is our mission: to create high-quality technology jobs in Middle America cities where talent is often overlooked. Our Mission in Action showcases Rural Sourcing colleagues who represent how this mission impacts individuals and the communities in which we operate. Jeanne Schmidt has had an impressive career in tech. For many years, she worked at PeopleSoft in Silicon Valley, where she watched the company grow from only a few hundred people to over 10,000 employees. She learned a lot during her tenure at PeopleSoft, and really enjoyed the culture, but after Oracle’s acquisition of the company, certain things changed. The culture she had come to love was no longer in place, and frequent meetings at Oracle’s headquarters meant a much lengthier commute. As the mother of two young daughters, Jeanne wanted to make a change to support a better work/life balance for her family. Heading east With the high cost of living in the Bay Area, Jeanne and her husband decided to start looking for jobs in more affordable areas, preferably on the east coast to be closer to her family. After her husband got a job in Augusta, Georgia, Jeanne enjoyed being a stay-at-home mom for a few years while her children were still young. Eventually, she wanted to return to work, and spent a couple of years at other organizations, before getting a call from a recruiter at Rural Sourcing in 2013. Challenging but rewarding Working at Rural Sourcing presented an opportunity for Jeanne that otherwise might not have existed in Augusta: the ability to work for “an impressive list of clients” while living much closer to family, and with a higher quality of life. Jeanne says, “Since I started at Rural Sourcing, I’ve been able to watch the company grow and maintain its fun, positive culture. I’ve been impressed with the type of project work we do and the list of clients we have. This is challenging, rewarding work that has allowed me to grow in my career and mentor others.” DISCOVER MORE

Our Mission in Action: Natascha Thomas

Our guiding force at Rural Sourcing is our mission: to create high-quality technology jobs in Middle America cities where talent is often overlooked. Our Mission in Action showcases Rural Sourcing colleagues who represent how this mission impacts individuals and the communities in which we operate. Before starting at Rural Sourcing, Natascha Thomas worked for companies where many young developers have dreams of making their mark one day, including EA Games and Disney. With the exciting subject matter, however, came some drawbacks. Natascha’s work-life balance was basically non-existent, and she had become defensive and untrusting of her colleagues due to the competitive nature of the office. Plus, she wasn’t able to achieve her savings goals because of the high cost of living in Los Angeles.  From the ocean to the gulf Natascha and her family decided to move to her husband’s hometown of Mobile, Alabama where she accepted an offer at Rural Sourcing. Here she found a much more collaborative and supportive culture: “I’m never ashamed to ask for help, and have never had anyone say to me, ‘you should know this.’ I can tell my manager if I’m feeling ‘underwater’ or have too much assigned to me without fearing that it could negatively impact my career advancement.” A better quality of life Natascha took to living in Mobile right away: “I think the things that really drew me in about Mobile compared to Los Angeles were the low traffic, clean streets, and polite folks with cool accents.” And while she hasn’t exactly grown fond of the “most massive insects I’ve ever seen,” Natascha feels as though living in Mobile and working at Rural Sourcing has truly given her the space to thrive. DISCOVER MORE

The Top 3 Benefits to Implementing Pipeline as Code

Any developer knows that a development pipeline can be a complicated and somewhat rigid set of tasks to work with, so imagine having the flexibility to rework and debug changes, easily collaborate with other developers, and implement changes gradually. In the past, this simply wasn’t possible; setting up a development pipeline almost always required you to run several different applications to make configuration changes which were rarely tracked, backed up, or annotated. They also couldn’t be easily debugged or rolled back if there was an issue.  So, what exactly does this mean? Instead of running these different applications to configure the steps of your build pipeline, you use something like the open standard YAML to create instructions/code that creates your development pipeline as needed. Some people may prefer to use full programming languages, since pipelines can be complex. However, with parameterization, configuration, etc., YAML or some other directive type format can serve the purpose in most, if not all, cases. No matter which path you choose to take, though, whether it’s using YAML or a full programming language, implementing pipeline as code comes with a number of benefits. Here are the top three.  1) Encourages experimentation The code, YAML, or whatever you decided on, is checked into your source control repository with its accompanying source code where it is versioned, tracked, and backed up. It can also be branched easily along with your source code for experimental improvements to the process. Before pipeline as code, if some problem arose after a build change, there usually was no way to go back to what worked to debug the change or changes that caused the issue. With pipeline as code being stored in your repository, you can easily generate a diff to see what changed, or you can roll back breaking changes to get back on track quickly.  2) You’ll get versioned builds Another benefit of pipeline as code is that as the application and the build pipeline changes over time, the correct version of the pipeline sticks with the same version of that software. It’s saved in the source control repository, safe and sound to where even older versions can be pulled down, used, tested, and deployed if needed, without fear that the build pipeline is now configured for a different version. This way, you won’t have to make potentially breaking modifications to the current build pipeline. 3) Collaboration With pipeline as code, it’s easy to collaborate on builds. When using other methods, you’re typically locked into using a tool that is an all or nothing option for edits to the process, but since pipeline as code, is, well, code, it can be edited in the traditional way that source code is and can be reviewed in the usual code review fashion. Changes to different stages of the process can be done by multiple people simultaneously and then merged together. Implementation concerns If you’re worried about a wholesale change in how you do your build, testing and deployment process, rest assured that your shift to storing your pipeline as code in your repository doesn’t have to be all at once. Some in your organization may be resistant to doing one big change, and you can assuage their fears with the knowledge that you can implement it gradually, so there’s no reason to hold back from getting started on this path. Now is the time to get started There are many tools on the market that support pipeline as code now, but it’s up to you and your organization to choose the one that best fits your needs. In each case, vendors have taken a lot of time assembling useful information to help make your implementation a successful one. This knowledge combined with the benefits above mean you shouldn’t be afraid to get started, and make the change to pipeline as code.  About the Author Barry Christian has been writing software professionally for over 30 years, and is currently the .Net Practice Lead in Rural Sourcing’s Augusta Development Center. He’s been involved with Microsoft's dotnet platform since its inception, and has helped author white papers for Microsoft, as well as written code for their official training curriculum. Barry is also a humor columnist for The Augusta Medical Examiner, and has published a mystery/thriller novel and is currently working on another. WATCH BARRY'S TECH IN 2 VIDEO ON PIPELINE AS CODE

Geopolitical Uncertainty Brings Risk to Offshoring

There has always been some risk associated with outsourcing software development. The question of which outsourcing option (offshore, near shore, onshore) is right for a CIO depends on an equation that addresses price, speed and risk. That equation, however, keeps changing as the risks of offshore rise, with the COVID-19 pandemic only adding to those uncertainties. A report from Gartner outlines major geopolitical concerns that are impacting both offshore and near shore development. “Political and economic stability is an important factor in offshore outsourcing arrangements,” said Jim Longwood, research vice president at Gartner. The outsourcing market has been relatively stable for the past few years, according to Gartner. But that may be the quiet before the storm. We've seen a trade dispute between the US and China, terrorist attacks in Sri Lanka, and most recently political tensions in Belarus. These global incidents demonstrate the potential dangers of relying on offshore development. “Gartner has started fielding more questions from clients about how to address these scenarios. This includes whether to stop sourcing services from a particular country, move services to another country or bring them back onshore. Each option is quite costly and can disrupt service delivery in the short-to-medium term.” “Concerns include potential disruption to or cessation of services, increased tax added to export labor rates and reduced quality of service due to ‘patriotic’ backlashes by local staff,” said Longwood. “All organizations should review their offshoring and nearshoring arrangements.” With so much instability with offshore development, it is critical for companies to proactively mitigate risk to ensure the stability of their systems. According to Gartner, that is leading companies to develop a multi-country sourcing strategy. Gartner predicts that by 2023, 65 percent of large companies will switch to a multi-country sourcing strategy. The sometimes overlooked category that has been added to the procurement strategy for many companies is use of the low-cost, onshore development. We’re seeing more and more companies add the category as a strategic sourcing bucket to meet ever growing digital demand. Onshore outsourcing can be competitive while bringing the added benefits of speed, improved communication and lower risk. By finding tech talent in Middle America, where there is a lower cost of living, companies can lower costs while maintaining the high level of quality and security that CIOs, CISOs, and CTOs demand. Plus, as we've seen during the COVID-19 pandemic, the U.S. adapted quickly to workplace changes, when other countries struggled. Great infrastructure, an evenly distributed workforce throughout the country, and a smaller learning curve have all helped the U.S. stand out as the most reliable option for outsourcing. Organizations cannot control geopolitical unrest, but they can control their exposure to risk. Onshore software development is the solution needed to manage risk, lower costs and ensure development work meets goals of speed to market and quality. DISCOVER MORE

Don’t Let These Four Fears Keep You From the Cloud

“Never let the fear of striking out keep you from playing the game.” Babe Ruth’s famous quote reminds me of the advice I often give to clients who are considering a move to the Cloud. Some organizations let their fear of change guide future plans, despite the Cloud’s many benefits which include cost savings, higher velocity and more opportunity for innovation. That’s why I’ve assembled the five most common concerns, and why they shouldn’t stop you from moving to the Cloud. Security There are numerous solutions to address this concern, but first and foremost it’s important to note that the public Cloud has had many years to mature and become battle tested; companies like Amazon and Google have spent a lot of money tackling security issues head-on. In fact, it’s more secure than your private server, which tends to be more vulnerable due to things like missed software updates, network compromise, or social exploits. However, if you’re still wary of keeping your company’s sensitive data on the Cloud, you can keep key data on a private server and move the less sensitive data to a serverless Cloud. 2. Legacy application issues Clients often think they have an app or process that they think can’t move to the Cloud, whether that’s because it’s built on special architecture or maybe tied to a specific piece of hardware in their center. And while it may be true that your business is tied to a legacy application now, switching to the Cloud can provide you with a level of independence you couldn’t dream of with private servers. 3. Organizational barriers Having a diverse team with different viewpoints and areas of expertise is a wonderful thing, but when it comes to being ready to switch to the Cloud, others on your team may not be as ready as you are. Consider this the perfect opportunity to be your project’s evangelist. In the Cloud, you can try all the new projects you’ve dreamed up for less than the cost of doing three of them in a serverless environment. I’ve found that the difference between a growing business and a stagnant one is whether you’re willing to embrace change. 4. Data handling concerns Sometimes companies are bound by data use agreements or regulatory concerns that make hosting their data on a public or hybrid cloud much more difficult. Maybe that data is jointly owned with business partners, or was collected under a restrictive data use agreement. Often, the data itself has been aggregated over years or decades from all sorts of sources, and you’re just not sure what you have to do to untangle all these concerns. There’s almost always an answer involving the correct security or private cloud integration. Additionally, you can find well-informed attorneys to help you understand what your responsibilities are if you don’t have that expertise in-house. I understand that moving to the Cloud can be an intimidating process, especially if you or someone on your team has any of these concerns. However, the rewards that accompany a shift to the Cloud can help your organization save money, move your business forward, and make life a lot easier for your developers. Listen to Babe Ruth – don’t let fear stop you from reaping the benefits of moving to the Cloud. WATCH TECH IN 2: ARE YOU READY FOR THE CLOUD? About the Author: Originally a medical researcher, Hoke Currie has been leading data analytics consulting and crossover software development teams since 1994 for clients including the US Army, CMS, Sodexo, DuPont, the World Bank, UPS, the Bill & Melinda Gates Foundation, and the International Monetary Fund. Formerly a managing partner at GraySail for more than sixteen years, he is currently a Principal Consultant at Rural Sourcing, and the Java practice lead in the Augusta Development Center. His specialties include Java, Agile development, Cloud adoption and migration, and large scale data analytics / machine learning.

The Need to Balance Work-from-Home and Work-from-Office

Work-from-Home (WFH) is here to stay. COVID-19 forced companies to adapt to the remote model or grind to a halt. Even companies that have previously resisted WFH have found most of their concerns to be unfounded. Some have even gone so far as to claim that the WFH/virtual model will be the dominant model going forward, and that offices are effectively ‘dead’. While there are significant benefits to a WFH model for many businesses, there are still potential downsides that technology alone can’t solve. After all, we as humans are social beings.  There is a reason ‘solitary confinement’ is considered severe punishment! Human connection and interaction are essential to personal happiness.  In-person team collaboration helps to build relationships, foster ideation and strengthen company culture.  And there are ‘moments of serendipity’ that can only happen when working in an office environment. WFH Has Many Benefits Working independently from home provides numerous benefits for employees and businesses alike. These include: Employee flexibility and ‘spirit of freedom’, giving employees control over where and when they workHigher productivity. Although WFH has its distractions, this is likely outweighed by lower commuting times and a longer window for working hoursBroader ability to recruit talent from remote locations – not being restricted by commute times to local officesLower facilities cost due to less need for permanent space and related support systems But WFH Also Has its Downsides WFH is not all ‘rainbows and unicorns’ – some of the challenges include: Employee burnout and disengagement due to longer hours, more time online and a feeling of monotony. In a recent study from DigitalOcean on remote work, 82 percent of U.S.-based remote-working professionals report feeling burnt out.Maintaining company culture and unity is challenging due to minimal personal interaction and connection, which in turn impacts consistency of performance and employee retention.Less in-person collaboration and interaction also reduces the opportunity for those ‘moments of serendipity’ where new ideas are generated, or problems handled quickly.  According to a recent PWC survey on remote working, the number one reason employees say they go into the office is to collaborate with other team members (50 percent). Difficulty collaborating is also the number one reason people give for being unproductive at home (39 percent).Ongoing skills and career development, as well as apprenticeship of junior employees can be a challenge, although this can be mitigated with investments in new systems, processes and training (both for managers and colleagues). Rural Sourcing – Taking a Balanced Approach The office isn’t obsolete, but it is changing. While the COVID-19 crisis showed that staff can interact well when apart, people still cherish in-person engagement with colleagues. Having colleagues interact in-person yields strong benefits to culture, innovation and ongoing career development. We feel the best approach is to blend the freedom and flexibility of WFH, with the personal interaction and collaboration found in Work-from-Office (WFO). Our development centers, located in Middle America communities, provide great hubs to enable this balanced approach.  We also feel there continues to be strong business benefits to our software development center-based model, including: Access to strong overlooked talent, and keeping IT jobs in the U.S.Lower cost of livingHigh quality of living compared to larger metropolitan areasA strong catalyst for bringing the innovation economy to Middle America As we at Rural Sourcing take steps toward moving colleagues back to development centers, our priority will be to maintain: Employee safety, well-being and satisfaction, and opportunities for in-person connection, relationship building and team collaborationProductivity and performance for our clientsEmployee skills and career development, including best-practice sharingCompany culture – preserving the ‘glue’ for retention, consistent performance and market differentiationOur focus on being part of, and giving back to, the local communities in which we operate – helping to build the technology hubs of the future We’ve always been intentional about creating ‘collision points’ for our colleagues to interact and work together. Now, we are rethinking how to do this safely. By strengthening the bonds our colleagues form in the development centers and across locations, we will drive greater collaboration and deliver even better results for our clients. Office space and its design are important pieces of creating a collaborative environment. That’s why we’re rethinking how best to use the space to create the type of location that fosters creativity and teamwork, rather than building just a heads down work environment.  This will include more teaming areas and better pair-programming setups.  Teams will be able to complete heads down work-from-home for part of the week and come into the office for sprint planning/grooming, difficult project points and greater innovation discussions. As we speak with our colleagues it’s very apparent that they want to return to the development centers. They don't necessarily want to come back to a ‘weird pandemic environment’ but do wish for the positive aspects of our pre-COVID environment and the ability to socialize/collaborate in person.  While we have all benefited from some aspects from WFH, we'll take the learnings from this unique time and build an environment that brings the best of both worlds together to the greatest outcome. DISCOVER MORE About the Author As COO for Rural Sourcing, Ingrid Miller Curtis is responsible for realizing Rural Sourcing's vision to provide US-based high quality IT outsourcing solutions through her management and oversight of all Rural Sourcing development centers. Her responsibilities include leading and developing Rural Sourcing talent, client relationship management, ensuring the scalability and reliability of Rural Sourcing's process and systems and strategically determining the next set of solutions for our clients. She is also responsible for establishing and ensuring consistency across the organization with respect to Rural Sourcing's processes, values, and methodologies. Ingrid brings an expansive knowledge of underlying computer systems and technologies, allowing her to contribute to all aspects of our application development and maintenance projects. Ingrid is a graduate of Babson College, where she earned a B.S. in Business Management.

No More Excuses: The Power of Code Review

Over the years, I’ve done a lot of experimenting trying to figure out how to help my projects and teams run smoothly and efficiently. The resulting bag of tricks gives me a strong arsenal from which I can pull, but not every trick in my bag is applicable to every organization, team, or project – except for one. The code review.  I’ve been invited into dozens of teams, but more often than not I’ve found a lack of commitment to the code review process, whether it was treated as a pointless formality or forsaken altogether. While it’s always disappointing to see, as a consultant, it’s low-hanging fruit that makes me salivate because I immediately know I’m going to be able to earn my keep and radically transform this team and project. That’s a powerful statement, and it might lead you to wonder,  “If it’s that powerful, why doesn’t everyone do it?”  There seem to be a few common “excuses” amongst the teams that don’t put any effort into code reviews: There’s not enough timeThe conversations become contentiousNo one participatesThey don’t add any value If you’re reading this, perhaps you, someone on your team, or both have used or subscribed to one of these excuses. Let’s break each of them down and dispel the negative narrative so we can banish these for good. Excuse One: There’s Not Enough Time Teams always need more velocity, and it seems most teams tend to underestimate the effort required to complete large projects. Tossing a production bug into the mix is a bit like throwing a grenade right into the middle of the scrum board. So we end up burning the midnight oil while praying for an 11th hour miracle so we can release on time. There’s no time for this pesky code review I speak of, right?  Code reviews make every member of the team better, stronger, more skilled developers through the knowledge share and coaching that happens as part of the process. The overall velocity of the team trends upward over time because your less experienced developers are getting feedback on every line of code they write, while your more seasoned developers are getting to see different approaches to solving complex problems, and being exposed to parts of the codebase they otherwise wouldn’t have any knowledge of. Sizing the tasks becomes a lot easier and more accurate because of this knowledge sharing that organically happens during the code review process. We’ve now effectively created a cycle in which the developer is getting better and has more exposure to the codebase on a daily basis. The result is a better codebase and better developers. It’s a win-win! Excuse Two: The Conversations Become Contentious We software engineers can be prideful, opinionated individuals. The most important thing to recognize and preach is that there’s no room for ego in the code review process. Everyone, no matter their tenure and skill level, can learn something from engaging in the process. This simple rule ends up cascading throughout the team culture and fosters a supportive environment that helps each member of the team grow on a daily basis. Excuse Three: No One Participates There’s nothing more frustrating than seeing a pull request sit there for days on end, which can ultimately lead to some pretty frustrating merge conflicts, or worse, the subsequent creation of functionality that doesn’t play nicely with that in the pull request. The bad news is that this comes down to team culture. The good news is that it’s easy to fix. Sit down with your team, explain the benefits and goals, outline the expectations and roles each team member plays as part of the process, and commit to the process as a team. The burden of holding the team accountable to the process doesn’t fall on any one person. It’s the responsibility of the entire team to facilitate this process.  Excuse Four: Code Reviews Don’t Add Any Value Time for some tough love. If this is the stance you or your team takes, you’re doing it wrong. It’s that simple. We’d be here all day if I tried to list all the ways teams get the code review process wrong. Instead, I’m going to give you some quick tips that you can take and put into action with your team today. (And look for deep dives into some of these topics in upcoming articles.) No egos, no arguing, be helpful, learn and help others learnTech leads should be on every code review, and their signature should be required to merge all pull requestsA total of two signatures should be required on every pull requestPost the link to pull requests into a common chat channelEveryone on the team should participateNo one is ever “too deep in the code” to take a few minutes to look over a pull requestKeep pull requests small, which can be facilitated through better task managementCreate a “code review playbook” that includes a list of things to keep an eye out for and that clearly documents your team or organizations code style rules (be sure to couple this with lint rules and auto-formatting) Newton’s first law of motion says, objects in motion tend to stay in motion. Sometimes the hardest part of the process is simply getting started. Make the effort to get a solid code review process in place, and the rest tends to take care of itself. I’ve had so many developers come back to me months later with a completely different attitude toward the code review process, even the worst of skeptics. If you want to see a dynamic and quick shift in the culture and velocity of your team, this is the easiest and most fruitful first step to radically transforming your team and creating an environment that fosters growth. The best time to plant a tree is 20 years ago. The second-best time is today.  WATCH TECH IN 2: THE POWER OF CODE REVIEW About the Author: Wes Dollar is a full-stack engineer with 21 years of experience in website & web-based software development. He has served as a business analyst & tech lead for clients ranging from startups to Fortune 500 companies. He has a passion for providing solutions to complex problems in a manner that is intuitive and easy for the end-user to use & understand. Most of his career has been spent on the open-stack side of the fence, where he has made many contributions to the Laravel (PHP) ecosystem. He is an HTML5/CSS3/JavaScript expert with strict compliance to W3C standards & 508 accessibility. He specializes in ecommerce & conversion rate optimization through UX design and also specializes in developing business systems, processes, and integrations.