Each company has its own working process, culture and ethics. Your company adapts a certain software development model for each software being developed per their requirement. Since each software development model has pros and cons, deciding on a software development process is vital for developing a product. However, if your company is not following any models, you are most likely following the code-and-fix model, especially when it is a small project.
The Beginning
If you belong to the IT field, I'm sure you had to write a piece of code along your journey. When learning to code, we encountered many code-and-fix instances, especially when we had not fully grasped the algorithm concept.
Sometimes we would try to solve the problems with the hit and trial method as we simply did not know how to solve them. We write the code, run it, find errors or bugs and try fixing them. This process, with time, became a popular method while developing products.
The Workings of the Code and Fix Model
An application is developed without any specific requirements or designs. Developers are provided with a brief description of the expectations of the app or a general idea of how the application should be. They work around that description and provide an initial build of the application. This first build is then improved, modified and improvised until the product satisfies the client.
As the name suggests, it consists of two phases; Coding and Fixing. In the 'Coding' phase, the software developers code and provide a build for the client. And in the 'Fixing' phase, the developed code is modified per the client's expectations, and the discovered bugs are fixed. All the modifications and changes are done in this phase to provide an application that satisfies your client.
The Misnomer
As the name suggests, it is a 'Model'. A model should define the structure of the process and how the project should flow throughout its development phases, depending on the client's requirements. However, no specific requirements are provided to developers in this model. Extensive planning and designing are not performed as well. Developers code and continue to code till the product reaches a state where it can satisfy its clients and users. Thus, the code-and-fix model can be considered a misnomer as it lacks a model.
The Inconveniences
The code-and-fix model is convenient for small projects in the short run. Developers have control to guide the development process in any path they prefer. Despite this, developers rarely use this approach for large projects, as no formal requirements and instructions are provided.
At first glance, it may seem as if following this model would reduce the development time as all you have to do in this model is code and then fix the code when a bug is discovered. However, many hidden overheads come with adopting this model.
A major flaw would be that there are no proper specifications or documents. Due to the lack of documents, developers may not clearly understand the real objective and how the client wants the final product to be. As a result, developers must do the work repeatedly, wasting their time and effort.
Code-like-Hell Approach
The code-and-fix model is more suitable for a small team. In the case of a big development team, miscommunication and misinterpretation issues take place, which can cause two or more developers to overwork the same project multiple times. Working until you are done, or the project is done, is the 'Code-like-Hell' approach.
Another drawback would be the implementation of new features and changes. If proper hierarchy is not maintained, it will be difficult to update the product. Developers might also have to rewrite a huge portion of the product, which only burdens them more.
If you somehow discover that your design approach is fundamentally wrong, you will have to throw away all your work and start fresh again. Any other model probably would have recognized this flaw in the initial stages of development. Finding a flaw in the foundation in the later phases can be costly in terms of capital and manpower. Moreover, it gives way to more bugs and issues.
Developers may fix a single problem without considering the change's effect on other app functionality. In addition, it becomes very difficult to assess the application and analyze the progress made due to the lack of requirements.
This is why this model is said to lead towards the code-like-hell approach.
Thus, developers in mid/large-sized companies do not prefer to adopt this model. However, they might use code-and-fix due to time constraints for situations like developing a prototype or preparing an application demo.
What It Means to SQA Engineers?
SQA Engineers play a vital role in maintaining and assessing the quality of a product developed in the code-and-fix model. With only a basic product description available, we must be vigilant to ensure the product is bug-free and satisfies the client. New features and bug fixes will have to be tested with each update. This may create a problem in automating the test scripts, or you may not be able to automate them depending on the product being developed and have to rely heavily on manual testing.
Is It a Bad Practice?
The code-and-fix model is one of the oldest software development models. Just because it has aged quite a bit doesn't make it completely unusable in the present tech era. In contrast, the code-and-fix model is still being used in early-stage tech startups. Typically, developers prefer this model while developing prototypes to access technical feasibility and the risks and difficulties that may arise while building the product. Thus, it provides a convenient solution for creating prototypes.
Every method becomes a good or a bad practice depending on where it applies. You cannot judge a fish by its ability to climb a tree. Similarly, you cannot declare a method is a bad practice by judging it in an unsuitable environment. The model works best for R&D activities, experiments, prototypes and low-budget short-term projects. Despite the flaws of this model, it can prove useful and better for developers if used in a suitable environment.
Hope you enjoyed this read. Let me know your opinion by commenting below.