What does it mean to develop an application? Usually, this means producing a piece of software that meets requirements by implementing certain features. And how do we do that? We collect customer requirements, estimate them, and develop features one by one. Right?
Do Not Forget About Bugs
Yes, errors do occur. Depending on the development process, software complexity, technical stack, and many other parameters, the number of bugs may vary.
At Keenethics, we commit to follow several optimal practices to minimize the probability of bugs to appear. In particular, our developers write a high-quality reliable code and run automated tests, while QA specialists manually test non-trivial cases.
In some cases, we pay more attention to QA in order to meet high requirements of a real business, which cannot afford critical issues in production. Other times, we leave QA out to speed up the development process (e.g. for prototyping). And yet, the QA theory claims that it is usually impossible to run an 100% test of the app and to cover all possible scenarios.
Nonetheless, to achieve the optimal result, the team spends a lot of time testing software and fixing issues, and this is the need that each customer should understand and prioritize.
Yet, this coin has a flip side. The longer you develop something, the more technical debt you incur.
So, what does "technical debt" stand for?
It is a metaphor, which comprises all the quality-related issues you have in the code that will require spending additional resources in the future.
Technical debt occurs due to a variety of reasons, such as:
- a business pushing to release new features faster,
- insufficient testing,
- rapidly changing requirements,
- inexperienced developers, etc.
Technical debt should be documented. If you do not leave TODO's in the code, most likely, you will forget about the issue, and even if you have time for it in the future, you will not remember to fix it.
Usually, you need to spend some time refactoring the existing code in order to solve code-quality issues and thus, to lower technical debt.
But what is refactoring?
It is the process of restructuring the existing code without changing its external behavior. And that is actually something that might be difficult to understand for business people managing the project.
Will we get any new features? – No. Will we at least fix some bugs? – Also no. What will we get then?
Working with technical debt helps to avoid bugs and to keep development at a good pace.
Sometimes, a business indeed might not need that, for instance, if that's a prototype or POC, or if there are business priorities that cannot be switched. But in most cases, cutting off refactoring would not be a wise thing to do.
At the same time, you might spend a really huge amount of time on refactoring if the developer is a perfectionist, which doesn't make sense either.
Therefore, you need to strike a balance. You should not spend more time on refactoring than you will save in the future, which does sound logical but again causes estimation difficulties.
Ideal refactoring is refactoring that does not actually occur. At Keenethics, we train our developers to think forward and to write a high-quality code, which would minimize the probability of bugs and issues. We also carry out regular code reviews, not only within one team but also between teams.