background picture

Saving Offshore Software Product Development Projects | True Stories by Developers

Visual representation of a developer

If you have already read some articles on the subject, you have probably come across the line by now, which says that about 1 out of 3 offshore software product development projects fail.

We have already gone through some of the more common reasons why most offshore software projects never see the light of day in one of our earlier articles.

In this article, we will tell the story of how we helped revive some of these projects through our work at RabIT software engineering.

Here are some real life examples of an offshore software development project turning south. Of course, we won’t be mentioning any names here, as the only purpose of this section is to point out that most failing software projects can be salvaged, even if things are looking very very ugly.

Case 1 – The spaghetti code that made no sense

Visual representation of a spaghetti code

 

About two years ago, a client approached us looking for an experienced software developer to join their existing offshore software development team. They were building a new online marketing tool that will make the client’s everyday work much easier. He is also planning to release it as a globally available SaaS solution later this year.

Our new client knew that something was very, very off about the code written so far, but he couldn’t quite put his finger on it, having no background in software engineering himself. So he basically hired us to have a look at the project and try to get it back on track if possible.

Our own CEO joined the client’s team of three other developers from the Philippines. We started by looking at the source code and running some good old tests on it. To put it lightly, it was a complete mess. Imagine a special kind of spaghetti code that was full of antipatterns, inefficient and illogical solutions, and was generally in very bad shape.

So we had our work cut out for us. The initial goal was just to clean up the previously written code, which was no easy feat itself. To test the current state of the source code we used code analysis tools like Checkstyle, CPD, PMD and JSHint. Checkstyle identified about 60,000 errors during our initial testing phase. We collected the necessary metrics, then got to work right away. It was essential to start with code refactoring, because at this stage the code was so unreliable that it was impossible to continue development work efficiently.

Several weeks and a lot of code cleanups later, 60,000 Checkstyle warnings turned into 1.500, which was low enough to allow for more efficient software development work. We also managed to solve some functionality issues that the previous team claimed to be unsolvable. As things started to fall into place, we could gradually focus more on developing new features, instead of code refactoring.

In the meantime, the initial development team was let go, and we took over the project entirely. This was never our intent, we work together with other outsourcing teams on a regular basis. The client made this decision after the other team continuously failed to meet our software development quality standards.

We are currently focusing on eliminating the remaining coding errors, while constantly implementing new features and design elements to the application. Despite the early setback, our client still expects us to deliver a top-quality finished product that is highly competitive on today’s market, and that is exactly what we aim to do.

Case 2 – When things go from bad to worse

Visual representation of reviewing a code

 

A couple of months ago, we were approached by two sport-loving entrepreneurs. They had a unique idea for a mobile application which is completely new to the market and does not have any competition yet. A small offshore software product development team from Russia had already started development by the time we joined the project.

The clients started looking for a senior software engineer because they were not satisfied with the work of the current developers. The Russian team claimed that some of the requested functions were impossible to develop, progress was made very slowly and the resulting code was unstable and unreliable. They needed someone who could see through the development process and had experience in leading a team of developers.

We started by running the usual tests on the source code, and the metrics were terrible. It was difficult even to get the application to run at that point. Three of our developers ended up joining the other team, with the support of a quality assurance tester and a project coordinator. Not much later, four freelance developers from India also joined the team.

 

Our responsibilities included project leadership, software architecture design, team coordination and software development. We were tasked with managing the work of the Indian team as well. Because we were ready to take over the entire development process, the services of the Russian team were no longer required.

During this period, we were still making a serious effort just to correct source code errors, but we finally started to make some progress. Problems soon started to resurface when the Indian team kept falling behind on their development tasks. They refused to follow the coding standards, and when we tried to enforce them, they were always one or two weeks late on delivery. Their code simply couldn’t pass code review, and this led to serious delays in development.

Our expectations weren’t unrealistic. We followed Google coding standards (to which we also added a few rules that we found important), and all parties unanimously agreed on the coding guide during our initial meetings. However, several weeks later, the Indian team also resigned from the project. We became fully in charge of full stack mobile app and server-side development.

By today, we have reduced static code errors from 30,000 to 800. Some serious deviations from coding standards and illogical solutions also ended up forming bottlenecks in the program, which we have since removed. We are currently aiming to focus more and more on developing new app features and less on code refactoring. If all goes according to plan, a live version will be ready to launch in September.

Case 3 – When code quality is not the problem

Pic of working people

Of course, code quality isn’t the sole reason why offshore software product development projects end up failing. We have just recently taken over one of our newer projects from another Hungarian development agency, simply because they were failing to meet their promised deadlines. This development team was almost one year late on delivery when the client finally decided to replace them with another agency.

The product is an E-commerce website with integrated stock management, invoicing and delivery management. The end result will be a highly customized software solution with multiple features that are completely new on the market. This time around, the code was beautifully written, and the former lead developer was very helpful and cooperative. It turned out that they had some serious internal management issues that eventually also led to the agency going out of business.

After some minimal adjustments to the source code, we could immediately start focusing on function development here. We are currently testing the final product together with our client, and it is set to go live in the very near future.

Summary

We have encountered more than 20 cases like these since we started in 2011.

Developing a unique custom software solution can be a risky endeavor. After reading stories like these, it is easy to understand why many business owners decide to stay far away from offshore software product development. However, by taking the necessary precautions during the selection process, outsourcing can become a reliable source of growth for your business in a small amount of time.

Remember, cost-efficiency is only one of the many benefits of offshore software product development. Hiring a highly competent and self-sufficient development team lets you focus on other areas of your business, and save a lot of time on recruitment and training, which also leads to a shorter time-to-market for your product.

If, while reading this article, you realized that you are in the same shoes as one of our clients was, or if you are just searching for a reliable software development team, don’t hesitate to reach out to us and tell us about your project at [email protected] right away.

Subscribe to our newsletter!

More Posts

If you have already read some articles on the subject, you have probably come across the line by now, which says that about 1 out of 3 offshore software product development[...]

If you have already read some articles on the subject, you have probably come across the line by now, which says that about 1 out of 3 offshore software product development[...]

If you have already read some articles on the subject, you have probably come across the line by now, which says that about 1 out of 3 offshore software product development[...]