Given Redberry’s extensive experience with rescue projects over the past nine years and our work with numerous clients, we recently sat down for a brief interview with our CEO, Gaga Darsalia, to discuss the journey throughout these years. He offered valuable advice for companies hitting dead ends with their software development and provided a glimpse into the tools and technologies that Redberry relies on in the development process. So, let’s dive in to discover more.

• Can you explain what the “rescue projects” are and how Redberry specializes in them?
  

We call “rescue projects” situations when a client works with a software development company on a particular project, and over time, it becomes evident that the project is headed in the wrong direction or has failed. In such cases, the project has little hope of being turned around and successfully developed to help clients achieve their business goals. 

Usually, clients put in a lot of effort to fix the problem and get the project back on the right track. But most of the time, these efforts to software project rescueing don’t really work. This is why clients ultimately have to switch to different vendors who can provide the necessary assistance to rescue the project effectively.

It was not Redberry’s goal to specialize in rescue projects specifically. However, our official partnership with Laravel and Vue naturally led many clients to approach us to help with their projects built with these technologies. So we’ve gained a great deal of experience by assisting different companies. Currently, rescue projects make up around 40% of our portfolio.

• What are the most common signs that a project is in need of ‘rescuing’?

Several signs can indicate that a project requires rescuing. For instance, when you initially plan a project and expect it to be production-ready in six months, but after three or four months, there’s no functional version in sight, that’s a strong indicator that it may not meet the go-live deadline. It is most probable that the project will get stuck in bug-fixing hell right before going to production.

Another situation to watch out for is when a product has already been put into production but has many issues. When one bug gets fixed, a new one pops up, making it extremely tough to see when things will become stable. This inconsistency can even make you doubt whether the product will ultimately offer a good user experience at all.

Besides, several factors can impact the project’s outcome, such as how well the team communicates, provides updates, maintains transparency during the development process, and follows a structured and documented quality assurance process. Internally, we’ve coined the term “development hell” that we use to describe such states of project development. And we discuss it in more depth in this video.

• How do you evaluate the state of a rescue software project before taking it over?

To evaluate the project’s condition before taking it on, we start by understanding the project’s context, its background, the industry it’s in, and other essential product details. Usually, we also ask clients for any available project documentation. However, in many cases, this documentation might be non-existent.

After that, we get access to the codebase, which is a vital aspect of the discovery process. Our engineering directors do the preliminary audit of the codebase for about two weeks before taking over. This step is essential as it provides insights into our overall strategy and the approach we should recommend to the client.

The outcome of the codebase audit is the document that includes our analysis of the existing codebase. This lays the foundation for defining our strategy for dealing with the existing codebase issues and further developing the product.

• What are the major challenges you usually encounter in rescue software projects?

1. There is no documentation and no written requirements, so it’s challenging to understand the code and the business logic.
2. The project is full of unreported bugs. There’s hardly any user flow that 100% works.
3. The codebase is outdated and in a horrible state with no automated tests. The data architecture is a complete mess.

• What are the key steps in turning around a project that has gone off-track? How do you handle the existing codebase in such situations?

We start by understanding the immediate business needs as well as their major pain points. 

Then, we implement our DevOps, quality assurance, and project management operations. Following our software delivery practices lets us slowly but consistently start delivering new versions of the software and shipping it to production.

It is paramount for our engineering team to become productive with the codebase. The only way to do so is to delve into it. Based on the business priorities and our strategy, we start fixing bugs, building minor new features and making the code better by iterative refactoring and covering it with automated tests.

Meanwhile, our QA starts testing and writing the test cases for the functionality we are working on. This creates a centralized knowledge base for everyone and serves as documentation detailing how specific features should be functioning.

• How do you establish trust with clients who have already had a bad experience before, and how do you manage their expectations?

Generally, our work delivered to the client speaks for itself. Our approach and methods often come as a pleasant surprise to them. The main thing we do differently is that we have a new application version that is put into production at the end of every sprint (meaning every 2-3 weeks). We not only address the initial problems but also transform them into tangible features that can actually improve the product. This usually becomes the main reason why clients really trust us.

Besides, in order to manage client expectations, we agree on a short-run (1-3 month) project roadmap with a client, and then we start iteratively delivering what we agreed on. 

• What advice would you give to other companies based on your experience of working on software rescue projects?

One key takeaway we’d like to share with other companies is to make significant changes earlier – when there is less technical debt in the project.

Moreover, if you want to understand the current state of a software project, we strongly recommend consulting with experienced and skilled third parties. Their insights into the codebase and overall project condition can be invaluable. Think of it as a consultation that can help you assess the project’s current challenges and find out where it can go in the near future. They can also help you determine if the project is heading in the right direction. 

Another thing to note is that paying attention to testing and documentation early on will pay off later as it will make the project more stable and easier to understand.