The Code and Fix Model
When one learns to code, the initial steps involve a great deal of experimentation with code writing and debugging. Note that debugging is the routine practice of finding and removing program errors. The learning process usually starts by writing the program and then finding all the software bugs and fixing them. This is a common approach that was originated by software engineers for tackling relatively easy and short-term challenges. However, in time, this procedure has become a widespread methodology in technology product development too.
Code and Fix (often known as Cowboy coding) is considered the simplest product development process and is the default method for prototyping software-oriented technology solutions. It is a cyclic process consisting of two major steps: Coding and Fixing. In this model, there typically isn’t an extensive product planning (sometimes a very simplistic one), concrete strategy, or well-defined design thinking.
The key participants of the process are cowboy coders — software engineers who are in charge of the work with very little or no guidance from business, design, or other relevant disciplines. Engineers will begin the Coding process after some initial discussions with the product team. Fixing usually occurs along the way so the team can fix the major bugs while working on the project.
Analyzing Code and Fix
Code and Fix might be very convenient for technology-driven solutions that are in their earliest stages of development, such as for engineering activities that involve research and development (R&D). To illustrate, people who are working on machine learning related research programs, where project outcomes might be uncertain and unpredictable, can find this model sufficient for their needs.
Additionally, software engineers love using this model when they are learning new technologies and development tools. It allows them to quickly gain enough expertise to contribute to the upcoming development activities. Moreover, the model allows engineers to reduce their scope of thinking and focus only on things that are the most relevant for their work. This can allow them to temporarily forget about technology and product impediments and to concentrate on building things that matter the most for that moment.
The Code and Fix methodology is sometimes considered a time saver and is a convenient option for low-budget products. It is very common in software groups, where there are many entry-level engineers interested in experimentation, observation, and learning to improve their coding skills. An example of this could be individual or group projects at the college-level Computer Science programs, where students have assignments to practice the fundamental aspects of their course.
Some software engineers might enjoy this activity because they receive full autonomy over the development process without any formal instructions from the managerial staff. In this setting, engineers are the ones who usually control the project’s creation flow, its scope, implementation details, technology stack, and the development tools while having no enforced software delivery structure. In some sense, this can boost engineering creativity. Also, the Code and Fix model might suit well for individual contributors — experienced software engineers who work independently on specific engineering aspects of the software, mainly on problems that are hard to tackle and involve a lot of trial and error.
At first glance, it might seem that the Code and Fix model reduces the time for product development. However, it involves a huge risk of failing to achieve customer satisfaction since there is no concrete understanding of product requirements and the definition of success (DOS). Furthermore, due to time constraints and the lack of quality assurance procedures, the project might have quality-related issues as well.
Moreover, the model is not designed to work well for medium-sized and large product teams. My practice as a cowboy coder has demonstrated that the methodology does not always reliably work when there are more than three software engineers in the team since there can be consistent communication problems.
Due to its experimental nature, it is also hard to estimate the delivery work when following the Code and Fix model. Teams that have uncertain outcomes may over or underestimate the amount of work that needs to be completed to satisfy their desired goals. In case the product team tries to push itself towards faster implementation, it can potentially cause to having an ugly code that is hard to read in further stages of development.
It can also be extremely risky to utilize Code and Fix for products that require future changes since new enhancements and feature updates might cause major architectural issues later in the process as there might be a need to rewrite large parts of the product. This is because technical prototypes are oftentimes not considered to be stable enough for future development. The initial engineering activities in this setting usually do not involve thoughtful research and software architecture-related discussions about upcoming challenges, eventually causing major technical debt in terms of code refactoring. Note that code refactoring is the process of changing the structure of the code without modifying the external behavior of the program.
Since Code and Fix is not designed for real-world software products, product teams often use this methodology to achieve short-term outputs, such as when there is an urgent need to quickly create an initial model of the product and present it to stakeholders. This development approach shows immediate results, making it attractive to many people inside the product team.
Despite being the most original and primitive software development model ever created, the Code and Fix is extensively used in many real-world products — especially in early-stage technology startups where all the founders are engineers. Another typically normal use case of the model could be when one or a few of the engineers inside the product team want to create a small technical prototype to assess the technological feasibility risks of the solution the product team is planning to build. This occurs when the feature or product requirement seems technologically challenging. It is recommended that the product manager gives engineers enough time to experiment so they can figure out whether the solution is technically feasible to build or not. This practice helps the team to reduce the risks of potential failure in the later stages of product development because of technology-related issues. Hence, the Code and Fix model is a convenient practice for rapid technical prototyping.
Being the most elementary software development model ever created does not necessarily mean that following Code and Fix is a bad practice. Like every other product development methodology, it has its advantages and disadvantages. Below you can find a comparison chart that discusses the pros and cons of this development approach.
By the way, I’ve recently worked with a strong group of software engineers for one of my mobile applications. The organization was great, and the product was delivered very quickly, much faster than other firms and freelancers I’ve worked with, and I think I can honestly recommend them for other projects out there. Shoot me an email if you want to get in touch — rafayelm@playengine.com.
