Once a potential client ordered our source code review service. The code was written by some freelancers and was quite poor — albeit not an absolute mess. The client got a detailed report about the mistakes, bad style and poor overall quality of the application.
The client (let us call him C) appreciated the results of the source code audit and asked me to thoroughly explain the issues to the developers who had written the code. He was hoping to get the issues fixed.
I told him, “C, they will not fix the issues. The code is just as good as their skills. They did all they could and actually built a more or less working website — at least it works under certain circumstances. They won’t do anything beyond that”.
He said, “Then you can teach them to use the right coding style”. I sighed, “You know C, we can teach junior developers. But only after they have passed our tests and joined us at one of our offices. It takes time and effort to acquire skills, so they should be motivated properly. We would rather refine your source code ourselves than teach incapable developers remotely”.
He said, “They promised to fix any errors for free”.
It was pretty much the end of that conversation. C wanted his free of charge fixes, which left me out of arguments.
Why bugs appear
Let us leave C with his poor codebase for a few minutes. I would like to talk about bugs in general and trample on free fixes.
All software has bugs at the development stage. There are many reasons why bugs appear apart from low proficiency of the developers, such as:
- weak communication with the project owner;
- lack of information about the workflow being automated;
- insufficient test coverage;
- presence of legacy code;
- improper quality assurance;
- commits done by a distributed team;
- high pressure applied to the development camp;
- a necessity to work overtime.
Therefore, there are many aspects that can affect the software development. Expertise of the development camp is not the only factor that matters. Even very capable engineers may commit casual bugs.
Let them fix those for free!
This is what is often heard from the project owners. The development camp may be tempted to agree with such a proposal because it is an easy way to resolve the current dispute. But it is not the way to remove the source of bugs.
To resolve a problem, one should know what the problem is, right? Now look at the list above and think about how many reasons can cause bugs.
If the communication between the business and the development is weak or one-sided, free of charge time will not prevent bugs from occurring. It is the communication that should be fixed.
If the development camp does not have a seasoned quality assurance engineer, it is a QA who should be added to make the development procedure consistent.
Advice to project owners
If bugs in your project appear rarely, don’t worry about them too much. Give your feedback and let the engineers fix the issues in the software.
If bugs appear constantly, find the root of the problem and fix it. Add what needs to be added, improve communication and see how it changes the quality of development.
If you are certain that there are too many bugs appearing due to lack of expertise of your development camp, find another software company.
Is there any use to insist on free bug fixes? You don’t want to insist on that. You probably know that the only free cheese is in the mousetrap.
If you seek a software outsourcing company who would fix bugs for free, you presuppose that your provider has developers who commit bugs for no reason. So, you are playing not to lose. I recommend playing to win. Just find a better provider and let them stay fearless and motivated.
Conclusion
What happened to C and his project? The previous development team tried hard to fix the issues but failed. They could make some minor adjustments but they could not refine the design of the application due to their small experience.
C stopped thinking of free cheese, returned to us and allowed us to help him. We brought the website to a completely different level and successfully launched it. The story came to its happy end.
If you are dealing with the same problem C had to deal with, we can help you too. Just drop us a few lines and we will start working on resolving your problem.
