This is another in our series of posts on software technologies we admire. Check out our previous post about Markable. This one is kind of cheating. We are picking Google. I know that does not sound very interesting because Google can do everything. That is true. But on a repeated basis I am blown away by their voice recognition and results capabilities.Have you tried the “OK, Google” feature on your Android phone? It feels like magic. But of course it is derived from billions of searches over the years.

Here is an example:

On your Android phone (sorry iPhone lovers), say “OK, Google”. Then ask any question you like. If you say, “What is the phone number for Home Depot in Madison”, the Google lady will tell you “The phone number for Home depot is…”. The phone number will also be displayed on your phone and all you have to do is click on it to make the call.

I have also started using the voice recognition for sending text messages. It is quite accurate and fast.

Even more amazing is if you say, “OK, Google, play Dinner Party Playlist on Spotify.” Boom. It opens up the playlist on your phone (assuming you have an awesome playlist called “Dinner Party” in Spotify).

I know Google has had their voice recognition for a long time. But just in the past few months it seems to have become more magical. I like it when technology is magical.

Do they have an API? Yes. https://developers.google.com/voice-actions/interaction/?hl=en They call it Voice Interaction API. I like OK Google better.

Having extremely accurate voice recognition could change a lot of things. Here are some ideas how it could be used.

1. Order food from your favorite restaurant. “OK, google, Pizzeria Uno, I want to order two Chicago Classics”. Done. It would have your payment information and address, if you want delivery.
2. Texting: Imagine going back and forth over text just by talking. It is not quite there but it is close. Could this be the killer app? With texting, it should automatically reply whenever you just say something. You should not have to hit the button every time.
3. Video and podcasts could all become searchable. I am guessing Google has thought about this.
4. Captions on video: All videos could have captions.
5. Google should come out with their own version of Amazon’s Echo. I’d like to stand in my kitchen and say, OK Google, please schedule a meeting for November 19th at 2:30pm with Dan Smith. That would be amazing.
6. Voice commands: You could use voice commands to control everything. OK Google could be the interface to make this happen.
7. Customer Service: If OK Google got good enough this would revolutionize customer service. It would change everything. There would be a ton of custom software intelligence for specific verticals and then companies. But if a company could use Google’s API for a specific use case, that would be awesome.
8. Visual Development Tool: How could these verbal commands and responses be taken even more mainstream? What if you had a visual tool that would match verbal words like “Pepperoni Pizza” with objects in a database. Then a technician could easily match up the verbal word Pepperoni with the ingredient Pepperoni in the ingredients table.
9. Complex Interactions: For more complex interactions, like a dialogue, a decision tree could be used to go back and forth. For example, if someone calls to ask about getting a toilet fixed, the decision tree could ask help guide the software agent asking questions to help diagnose the issue over the phone. That would be cool. And the toilet example sounds super exciting

What other ideas do you have?

Our friends over at Toptal wrote a great post on remote workers. It’s an interesting read. Thanks for sharing, Toptal.This article did a great job showing how remote software developers can be a great resource for your software development team. More and more distributed software development will be the norm, not the exception.

http://www.toptal.com/freelance/busting-the-top-5-myths-about-remote-workers

This is the second in a series of posts about the process for software development project based work. This post is on gathering basic requirements. Check out our previous post about the Ideation Phase.

So why do we need to gather basic requirements for a software product, mobile app or web app? At this stage it is to better understand a potential client’s vision and how we will implement that vision. The basic requirements are meant to flesh out this vision in order to provide an accurate proposal.

To be honest, this stage is not as interesting as the ideation phase. But it is just as important. Ideas are great but the basic requirements gathering stage is where ideas start to take form and become reality.

Our previous post was about the ideation phase where we talked about a new music platform our client wanted to create. Now we have to decide out of all those ideas what features and ideas should be implemented.

For example, live streaming of concerts would be awesome. But logistically there may be a lot of stuff behind the scenes. Because of that, the client wants to wait and have that feature developed in Phase II or III.

This basic requirements gathering is critical to distinguish which features should go in specific Phases so that we can provide an accurate quote and the client can plan the cash needed to develop the software product or mobile app.

So what features does our client want in Phase I? This is often called the minimum viable product. Sometimes it is called Phase 0.

Let’s say for Phase I, the client wants the ability for customers and artists to register and have a profile. They also want the ability for an admin to have super privileges over all of these pages. These features are essential to our example client. But you could even get away with less. Fans would not have to be able to sign up and have a profile. Every feature and functionality has to be evaluated independently.

For Phase I, the client also wants ecommerce functionality and the ability for artists to sell rights to their songs to their fans.

There are of course other details that need to be worked out. But it is important to understand the vision for Phase I, II and III.

For a software project like this we would also ask a number of other questions:

• What type of administration roles do you want?
• For mobile, do you want native mobile apps or just a web responsive site?
• Are there certain websites or apps that you want this to look like?
• How do you want the website to flow? This will become more important during the full requirements gathering stage.
• And a host of other questions.

I hope this gives you a brief idea of the basic requirements gathering stage.

Hiring software developers is never easy. You need to hire based on experience, skill set, productivity and personality. And software development is more finicky than hiring someone for sales.

So from Madison, Wisconsin, how do we hire our offshore software developers in Coimbatore, India? Lots and lots of experience.

Here is the typical process:

1. New Project: Client has a software development project (mobile app, website, web app) they want to develop. We help identify the technology they want to use. This could be .Net, PHP, front end technologies, CMS (wordpress) or ecommerce (magento).
2. Skill Set: Once the technology stack is identified then we identify a software developer that has the required technology skill set. This developer is sometimes already in-house or we may have to find a new developer in India to bring on board.
3. Must be picky: We only hire very good developers. In Coimbatore there are six engineering schools. A wealth of talent exists there. But realistically, less than 50% of software developers could be employed in the United States. The rest just do not have the proper skills.
4. New hire: Let’s say we have a new hire. Like any company, we first weed through applications. Typically we want someone with at least 5+ years of experience. On rare occasions we would hire someone straight out of school but that is risky and unusual.
5. Interview Process: The candidates are first interviewed by our HR staff in Coimbatore. This is the first round of screening. If they pass that round, then Sajan (our CEO) does the next interview for our candidates over Skype. Sajan has hired many developers in India. He asks them a series of questions to test their knowledge and experience. We also review their past work. If there is a question of their technical capabilities, then we will have the candidate do code testing.
6. Technical Talent: The technical talent of software developers in India is very high. As we have talked about in previous blog posts, they are very good at taking software requirements and coding them.
7. Trial Period: We have found the best test is a two week trial period. This is where you get to see their capabilities. This is also why we offer a full refund to our clients if the first two weeks are not a positive experience.
8. Project Management: To help evaluate our software developers, and ensure quality projects, we are very hands-on. We never just throw a software developer at a company and hope for the best. That is why disasters happen. If things are not working out for some reason, we want to know immediately so we can take action.

I would like to say that we have a crystal ball and we always hire the perfect developer every time. We do not. But through the years we have refined our process to ensure that most of the time we hire very good developers.

This is the first in a series of posts about our project management process for our offshore software development projects. This applies to mobile applications, web applications and pretty much any type of software product. We are obsessed with structured software processes to ensure quality. And we have found that structure allows for more creativity because we don’t have to worry about the process, and can focus more on the end product (mobile apps, web apps).

Sometimes the easiest way to understand a process is to look at an example. How about a new music platform based in Madison, Wisconsin?

This particular example is a consumer facing website. But Augment works with many business to business software products as well.

So, what kind of music platform are we going to build? I want a platform where you can be a part of an artist’s community, see the artist rise up and thrive and be a part of that ride.

So let’s pretend a client comes to us with this idea. How would we start? They have an idea of what they want but the details aren’t quite there. The first phase would include ideation and basic requirements gathering so we can submit a proposal. Ideation involves brainstorming the possibilities of all those little details. Basic requirements gathering involves understanding how to implement those ideas and what ideas should be in phase 1 versus phase 2 or phase 3 of the project.

This blog post will focus specifically on ideation.

Here are some details that the client is interested in incorporating and possibilities we would need to discuss. We love this early part because it is where ideas start to take form and become reality.

1. Distribution: One of the first questions I would ask is how will they distribute their product? Ideally they would have multiple musicians interested in the platform before they develop it. Even better they would have interested musicians who could recruit 100 other musicians. Distribution is critical. Websites do not sell themselves.
2. Rank Artists: The client says they want to rank artists, but they are not sure how. How about ranking artists based on number of views on youtube, listens on soundcloud, fans on facebook, etc? Ideally we’d also incorporate concert ticket data but that will be more difficult to get. Then we can come up with an algorithm to determine the ranking for each artist. This way you could follow your artist as they rise, or fall, through the music industry.
3. Live streaming: Cool. How can we make that happen? Is the client OK using youtube’s live streaming capabilities? That would make development faster and easier. They would also have some extra distribution through youtube as well. Otherwise we could incorporate a standalone video player. In terms of software development, this would not be much more difficult, but the additional servers required, or bandwith they would need to buy, would be expensive. On the upside, the client would have a lot more control.They’d also like to be able to connect ticketing to live streaming for an “online only” show. For this, Eventbrite.com or another service could be incorporated, which would not be too difficult. The tricky part would be figuring out how to easily sign up artists and connect their bank accounts to whatever ticket service we are using. The actual connection would not be difficult, but figuring how to make it easy and seamless for the user could be more challenging.
4. Voting: This could be like teespring except each musician would have their own platform. Is there a third party software already available to make this happen? Or will this software application have to be developed from scratch? And should this be a part of the mobile app? Having voting available on a phone would allow for voting during a concert or event.
5. Ecommerce: The client wants musicians to be able to sell their paraphernalia, including custom items like ringtones, to fans. For this we could use a number of applications. If we are using wordpress for content management we could use woocommerce. We could also use magento or a multitude of other products as well.
6. Lodging: Fans should be able to stay with each other when they’re on the road. It would bring the community closer together. You would have to deal with insurance and security issues. Is it worth the risk? What if the platform had insurance just like Airbnb.com does? This software would likely need to be custom built.
7. Sell rights: Allow clients to sell rights to their songs, concerts,etc. This can be done through different blockchain apps. Some custom software development by our offshore developers would still be needed. I think bitshares.org would be the best platform to try out. This idea would make fans an intimate part of their musicians’ enterprise.

This example of building a new music platform includes the client wanting to add multiple different features which can add a lot of complexity to a project. It’s very important to really look at the details in the ideation stage so we can figure out which features our offshore developers can add by incorporating third party software, which they will need to build from scratch and which will need a little bit of both. It’s also important so that in the basic requirements stage, we can discuss which features will fall in which phase of the project. A thorough ideation is the only way Augment and the client can be on the same page and it’s the first step to a successful project.

This is the first of a blog series on companies implementing new and creative uses of software applications and mobile apps. Often this includes using machine learning and predictive analytics, both of which will become more and more an intimate part of the software development process.

I know one of the developers at Markable. He’s based in Madison, Wisconsin. They have an api for photos that can detect the type of clothing from a photo. That’s impressive. It’s like shazam for clothing.

Here is a screenshot from Markable’s website:

I’ve never used it, so I’m not sure how well it works. The idea is sound but it’s not revolutionary. It’s greatness is all in the execution. If it works well, you can imagine seeing a photo on facebook, being able to click on the “must-have” clothing to see what it is and then actually purchase it right then.

Taking it one step farther, what if you were wearing the Microsoft HoloLens and as you walked around it would tell you what people were wearing. To do this in real-time could be tricky but if Markable took a snapshot of the desired clothing then it shouldn’t be too much different from their current process.

What other applications could be developed that could help you detect objects?

Some immediate other uses would be other attire: shoes, watches, sunglasses, jewelry. But let’s think beyond this. What other products/services could software eat up and spit out? Any product out there in the world, but what categories would make the most sense to tackle next?

What about categories that are fairly similar to apparel where products aren’t already known by the industry? Construction equipment could work but the people in construction don’t need to be told what a hammer is. It needs to be categories where discovery would be valuable.

Plants and flowers would be awesome. I imagine this wouldn’t be easy. It wouldn’t be very valuable from a commercial standpoint but lots of hobbyists would love it.

People’s faces. Lots of companies are working on this. This would be ideal with Google Glass so when you walk up to someone you know who they are. This use case isn’t too new.

What about the in the business to business space? It could be quite useful for training.

Imagine that you’re a new college grad that just started work at a large John Deere manufacturing plant as an assistant plant manager. You won’t have a clue what anything is initially. Using something like the HoloLens, the entire manufacturing plant could come alive. You would know which line is scheduled for what and you’d be able to quickly understand how to operate each line, because instructions would appear before you as you walk down the line.

You may not be operating the line but you’d know how. And this would work for any of the hundreds of people who start at the plant over the course of years. Training is expensive. Machine vision and clever software applications could make it much easier especially for the Millenials where digital is in their blood.

What other ideas do you have?

One of the main reasons we started Augment is to help small and medium sized companies better compete with larger companies who have larger funds for software development and app development (Android and iOS). Innovation is a major part of this ability to compete. What in the world do innovation and offshoring have to do with each other?

A lot of innovative companies like Google and IBM offshore a huge portion of their workforce. Does this make them creative just by offshoring? Of course not. But offshoring allows them to have more productive developers coding and implementing new innovative ideas.

The same is true for startups and small and medium sized companies. Offshoring parts of their software, mobile and app development allows these companies to iterate faster. Companies that aren’t doing this will be more and more at a disadvantage. Companies that have raised tens of millions of dollars might be fine hiring all onshore resources but for the rest of the pack, offshoring is a way to compete through innovation.

So how should this be set up?

It’s similar to our previous posts about keeping design and architecture onshore and offshoring the actual coding software development work. This is how we do it.

I know of one predictive analytics firm that also does this. The speed at which they can iterate is amazing. I call their structure “the iceberg”. They have a small team located in the US – the visible tip of the iceberg. This team is composed of the CEO, CRO, CTO, CMO, head of services, admin assistant, COO and VP of tech. That’s pretty much it. The creativity and direction comes from this team. The rest of the team is offshore software developers, about 25 of them.

This iceberg structure, where the creative and delivery are at the top, and the development down below, allows this firm to react and develop like a medium sized firm while only having a few people in the US. Recently they had to pivot from the retail/financial industry to the healthcare industry. Their app development speed was breathtaking.

Plus, offshore software developers can also provide a new perspective on development or a business model. They may not always be as creative but they can provide new perspectives on application and software development when asked to do so. It’s fun.

Offshore software development is key for innovative companies. Augment is part of many innovative companies and we hope we can be part of many more in the future. It’s a humbling and thrilling experience to work with such creative companies and people.

There is always a lot of concern with offshoring software development. This blog post will address issues and recommendations from a paper on offshoring custom software development projects. We don’t want to bore you by reviewing a paper but we are always looking for advice to improve the offshoring experience.

The authors give some of their own recommendations but also pull a lot from previous research.

Reasons for Success and Failure in Offshore Software Development Projects

Before we look at the authors’ project and findings, we need to define what failure is for a software development project. The authors have cited another paper (Linberg, 1999) where failure is defined as such:

[A] project that is cancelled or that does not meet budget, delivery objectives and or business objectives. Delivery objectives and business objectives include scope, quality and time. Therefore, an unsuccessful CSD project can be defined as being cancelled, or failing on one of the four success aspects: delivering software that does not meet the requirements, not meeting the expected quality, not being completed on time, or exceeding its total budgeted costs[.]

Background
For this paper, 19 offshore customer software development projects were analyzed. The onshore component was in the Netherlands and the offshore components were in Malaysia, Romania and India. The size of the projects ranged from €30,000 to €60,000,000.

Findings
In their analysis, about half of the projects were successful as a whole. Over half the projects were successful based on scope and quality but less than half were successful based on costs and timing.

Let’s look at some of the specifics.

Experience:

The more experienced teams had more successful software projects. Project teams that knew each other beforehand also had more success. That’s not a surprise. But it does suggest that new teams should have an introductory period get to know each and their work/code styles.

That’s probably too many people on one project.

Project Size:

Smaller projects (less than 25 people) with a shorter timeline (less than 9 months) were also more successful. Once again this is not a surprise. But it does suggest large projects should be broken down into smaller pieces. This would allow large projects to gain some of the efficiencies of smaller projects.

Comments from Project Participants
The authors gathered comments from participants in all the software development projects. Somewhat surprising was that lack of standards was not indicative of failure. Having clear responsibilities was stated as a big reason for success.

Participants in successful software projects mentioned informal mutual adjustment as a major reason for success. This has to do a lot with constant communication, which is essential for any software project, onshore or offshore. Constant communication allows the project manager, the developers and the client to be on the same page and address issues when they arise. Those issues could include poor quality, a communication problem with one of the developers, or lack of direction by the project manager. Sharing of all documents was also indicated as an important factor for success.

Participants of unsuccessful projects blamed poor planning for the failure of their projects. This is not a huge surprise. It shows the importance of writing detailed and understandable requirements at the beginning of the project. It also suggests the importance of setting expectations with all the parties involved, including the client.

Here’s a great chart from the paper listing what made for successful and unsuccessful offshore software development projects.

So, how can an offshore project be successful? Project management and coordination must adapt to new dynamics with offshoring. The authors recommend the following five coordination areas that are key to a successful project:

1. Standards: all methodologies, rules and procedures should be documented and followed.
2. Planning: Schedules and milestones should be understood by all participants.
3. Formal mutual adjustment: This measures the quality of formal communication. Is there a daily scrum?
4. Informal mutual adjustment: This measures informal communication like skyping or a daily lunch.
5. Team selection: How does the team work together?

The paper then states that it’s also important that an offshore team’s schedule has some overlap with the onshore team.

What About Diversity of Staff?
Linberg (1999) stated that offshoring can increase diversity leading to a stronger team and better quality. In several follow-up papers, (Chan & Chung, 2004; Paasivaara & Lassenius, 2006; Layman et al., 2006), the authors found that diversity can lead to poor communication. We have been involved in both types of projects. For those projects that had poor communication, it was likely due to poor planning and execution and not diversity. On a number of projects we have found that diversity is a strength.

Offshore software projects need to be carefully planned and executed. Offshoring can increase innovation at a company because they can do more with less. But it needs to be carefully done. Did I already say that?

Software development is becoming an increasingly geographical distributed process, especially here in the US. No more do we have the entire development staff working under one roof or even geographical location. Cost cutting, work from home options and business travel have contributed to the workforce being more globally distributed.

From a network security and risks standpoint distributed workforces have made the task of security more challenging. With more and more companies depending on an offshore partner the challenges are more complex.

At Augment we often get asked about what type of security and policies we have in place with our office in Coimbatore, India. It’s a great question and one that everyone should ask their offshore partners, even if it’s just one person working from home in India.

The Security Challenges of Offshore Development, from The SANS Institute Reading Room dives into some of the security issues of offshoring software development.
This paper presents a scary outlook of using offshore development teams for your software development projects. But keep in mind there is a whole host of security issues lurking in your local office as well. Also, some of the challenges presented in the paper apply to remote developers working here in the US as well.

Let’s look into some of the risks presented in the paper and then look at Augment’s approach to mitigating those risks.

Loss of Control:

The main issue presented in the paper is the lack of control on the development process because it’s taking place at an offshore development center. This risk is indeed very real and affects the quality of the code that is produced.

So how do we mitigate this risk?

1. Development Standards: At Augment this risk is usually mitigated by the use of development standards imposed on not just the offshore team but also on the onshore team. Everyone working with the same set of standards helps to ensure code and the project is executed as prescribed.
2. Review of the code: We also recommend a peer-to-peer review of the code written by offshore and onshore developers. This process might add to the development time (maybe around 5-10%) but ensures a standard set of code and eliminates most of the Loss of Control risk.

Case Study:

In order to explain this a bit further let’s look at a real life example. Augment has a team of developers helping a client in Madison, WI with their extensive backlog of maintenance issues. When the offshore team was brought on board the orientation included extensive training on the client’s internal process used for software development and deployment.

Here’s how we set up the process with our offshore developers:

• The code repository was branched and with a separate branch for the offshore team to commit their code to.
• Each commit (usually a feature or resolution to a ticket) would raise a request for peer review of the code change.
• The reviewer would then approve the code or reject it with relevant comments.
• The client also had an internal system where none of the offshore developers had access to Production code or the database. The offshore developers would simply add their change to a Deployment Checklist. The Deployment Checklist was the basis for the deployment team to make changes to the Production environment.
• This simple process enables the developers to do their job free from the complexities of the Production environment.

Network Complexity:

Networks are complex by nature, one reason why many network admins make six figure incomes. The more people and nodes on the network from different areas, the more complex it becomes to manage the network. Offshore resources do add an additional level of risk since the network and policies are outside of your domain.

To a large extent appropriate and relevant access, firewalls and additional DMZs mitigate the risks to a certain extent. Unfortunately, the threat of breaking into the corporate servers via a third party is ever-present. Careful evaluation of the offshore vendor is certainly needed but more insight into their written network and security policies is also required. However, irrespective of the written policies ensuring 100% protection is almost impossible.

The popular adage “the best defense is a good offense” applies to network security as well. Being on the offensive when it comes to monitoring traffic, applying the latest security patches and assigning just the right level of access for various personnel goes a long way to maintain network integrity.

At Augment each of the development teams are given just the right level of access to the development server. Many times the software code resides on a central repository and access is granted only for the project the resource is assigned to. All code is checked into a separate branch that is then merged by an onshore developer after a thorough code review. All Augment developers are trained to be responsible with the access. Passwords are never shared and substitution of personnel is only done with permission from the client. At Augment all developers work from the same office (owned by Augment). Physical security, restricted access to floors, surveillance cameras, clean desk policy, network best practices and random audits all assure the projects and the resources are all working towards a common goal – quality software development for the client project.

Legal and IP Issues:

With the use of offshore vendors and resources there is always the possibility of the client’s IP being misused. Most offshore vendors are reputed and continue to execute projects for many small, medium and multi-national companies with few issues involving IP. Companies should of course sign a Non-Disclosure Agreement (NDA) and a Privacy Agreement. IP ownership rights on existing IP and IP developed during the project should belong to the client.

Augment’s founders have had zero incidents involving IP issues in their careers. Below is a summary of Augment’s policies and procedures to assure clients that their projects are safe and will get executed professionally. This list will give you a feel for what an offshore vendor should have in place for security controls and should be used when talking to any offshore vendor.

Our Infrastructure

• Located in a fully owned building
• Over 120 staff with exposure to international projects
• High speed internet connectivity with redundant lines
• 100% power supply – UPS and Backup Generators available
• Physical security in place 24/7
• Surveillance cameras at all vantage points to constantly ensure security of client information
• Access controls in place
• Network restrictions to ensure that only the relevant personnel have access to client related information stored in File System, Source Control, Staging Servers, Production/Web Servers, Backup Server and Email
• Firewall protection at all times for all incoming and outgoing traffic
• Frequent system monitoring in place to ensure prevention of any untoward incidents
• No access to USB ports, Pen Drives, Printers and External mails for the team so that client information and source code remain protected at all times

Intellectual Property Protection

• Any improvements to Intellectual Property items held by the client or its end clients, further inventions or improvements, and any items of Intellectual Property discovered or developed by Augment, LLC for the client or ultimately for client’s end clients shall be the property of the client or its end clients.
• Augment, LLC will sign all documents necessary to perfect the rights of the client or its end clients to such Intellectual Property, including the filing and / or prosecution of any application for copyright or patent. Augment, LLC will sign all documents necessary to assign the rights to such Intellectual Property to the client or its end clients.
• All employees of Augment, LLC execute the non-disclosure and intellectual property agreement internally with us, which will prevent misuse of client proprietary information as well as end client proprietary information.
• A general vigil on the activities of the employee is also maintained to ensure that there is no threat to the agreements made between Augment, LLC and the client.

Security Audits

• Risk management system: The risks are mitigated with the help of Usage Guidelines, Security Policies & Procedures, Backup Policies, Emergency Procedures, Regular Maintenance and System Audits.
• We also have a physical security service in place to monitor and restrict access of unauthorized persons at the office entrance. All employees are provided with identity tags and only those in possession are allowed access inside.
• In addition to physical restrictions, we have tight access control to computers, secure firewalls in place and use the latest anti-virus software.
• Network restrictions are in place, whereby authorized personnel are only allowed access to relevant information. Dedicated 24/6 system administrators.
• We have a system in place to reduce overall messaging volume and protect against spam, spy ware and other security threats.
• For integrity, testing of software code is performed before any system is implemented to ensure the data does not become corrupted and regular logging and log analysis is also performed to provide debugging and assistance with incident response.

In an earlier post we mentioned this article from The Atlantic that warns of the many pitfalls of offshoring software development.

Behind the ‘Bad Indian Coder’

Although Augment’s focus is to help companies successfully offshore software development, we do agree with virtually every point in this article. The key to a successful offshoring experience is to find the correct talent and have processes in place to ensure great quality and communication.

Let’s break down some of The Atlantic’s points.

“Code from India can be truly awful if you work with most companies,” another Redditor said. “A lot of them treat programming as a task to be completed with numbers and fire those that can’t work fast enough, rather than a task requiring quality where people are educated to avoid mistakes and fired only as a last resort.”

We agree. We’ve worked on some offshore projects that have been disasters. These projects had poor communication and the initial database, design and overall architecture set the project up to fail from the beginning. You live and learn though. As in any occupation in any country, there are definitely software engineers in India that should not be employed. But many are good employees who may need some oversight, strong feedback and encouragement to become great employees.

Like the quote above alludes too, Indian programmers are people, not simply cogs in a machine. They want to feel like they’re a part of a team building something. They may be thousands of miles away from the company they support, but they also have the same fears and worries about their job performance and the project as their onshore counterparts.
“For some projects, we tried architecting and planning it all out in detail over Skype, but it never worked well,” he told me via email. “Invariably questions come up during the development phase, with decisions needing to be made. With an 11 hour time difference, their options were to either wait for the people on the other side of the world to wake up for a consultation, or make a judgement call. Both options suck given that they don’t have the general knowhow about the industry and the customers that we do, but waiting till we wake up [would mean] a wasted day of work.”

We’ve experienced the same thing. That’s why we believe planning, design and architecture should stay onshore. There are special situations for a simpler project where these items could go offshore but overall they should stay onshore.

That’s because planning, design and architecture set the stage for the entire project. If requirements are not clearly defined and incorporated into the architecture and design, then the entire project will be off base from the beginning.

The part of the project that should be offshored is the backend and frontend development. That’s it. Offshoring even this portion can help companies save significant time and money.

We also recommend to work with offshore resources that can work in your time frame. The developers at Augment work early morning to mid-day so there is always overlap with the onshore team, making collaboration simpler. No waiting until someone wakes up.
“I think the Indian education system as a whole is greatly flawed in that it does not urge students to think, but rather to memorize, or ‘mugging’ as they say in India,” he said. “Essentially if you can stay up all night before an exam and cram as much information as possible into your head, you will do pretty well on tests.

Kulkarni felt this partly explained why his Indian staff created products that had been programmed before they were fully planned out, forcing the New York team to rewrite entire programs from scratch on occasion.”

That’s why we think the planning needs to stay onshore as much as possible. Unfortunately articles like this one broadly categorize all Indian developers as unimaginative, uncaring and inflexible. That’s not true at all. The education system in India may be different than in the United States but we’ve worked with many developers who are quite creative and hungry to learn more and adapt.

“Weighing in on the buggy Indian code debate, Indian developer Shekhar Gulati wrote on his blog, “In India … students just cram the things and get [the] score but practically they know nothing.” Gulati pointed out that he once interviewed a computer scientist with a degree in the field and six years of experience who was unable to write a simple program during his test.”

This is again a broad generalization using one example to label the entire Indian software developer workforce. But it is something to be aware of. All developers (whether onshore or offshore) need to be properly screened to make sure they’re savvy and competent.

It may take more effort to properly screen an offshore developer, but they can be screened in the same way and using the same questions/tests as any onshore developer. Skype and other screen sharing programs are great for this. Once in place, a properly screened offshore developer can be a very effective member of an onshore team. Also working with a quality offshoring firm can help with the screening of individual developers, and they can also ensure the quality of the work and help facilitate communication.
Augment guarantees the quality of all development work performed by our offshore developers. We also work very hard to achieve seamless communication between everyone working on the project.