Emergency-Button

How to rescue a software project?

We are not magicians!

We can neither recover a project that is full of programming bugs or design failures nor can we rescue a project that is months behind scedule. We also can not increase the "output" of a development team by

    n Developers * x Hours.

The attempt to bring delayed or depressed projects back on track by just adding more people will always fail. What we can do is analyze and resolve specific bugs or problems. Typically these are program crashes, performance problems or other dysfunctionality.

 

For a developer, difficult and complicated bugs that remain unresolved are annoyances, that lead to a heavy personal burden over time. Such failures keep developers away from developing, and they can be very frustrating. All members of RED SOFT ADAIR have experienced situations that raised a deep desire to have someone come in and resolve "that nasty bug...".

For us, software problems are a challange that we face with enthusiasm. We only have one target that we want to reach as fast and as good as possible: Find and resolve the problem. Thats the only reason why we show up.

This brings relief to the developer - he gains support and he may even take care of other missing features.

We leave behind an uncluttered field and written reports. The optimal solution will be agreed to together with your developers and project managers.

 

Our Advantage

Its our advantage too that we have to draw a new unbiased picture of the existing project on blank paper. This sharpens the view in conjunction with our many years of experience.

We are not magicians! We come in order to help in difficult situations and to give support when something went wrong or if the existing staff is not or no longer able to finish the project. We want to fulfill our assignement as quickly as possible and leave behind a project that the existing team is able to continue. Therefore we see ourselves as first aid or possibly as a guide. We do not aim to take anyone's job away or to interfere in a company's human resources policy. In all phases we will speak openly, without finger pointing, to both developers and management.

We also do not aim to criticize or discuss any design- or architectural decisions that have been made in the past. The software we meet is as it is. We want to resolve the most important issues. This still may lead to changes in software architecture, but we will abstain from blaming anybody.