Practice
«Crutch-driven development» is a concept that emerged in the era of the growth and popularization of high-level languages such as C++, PHP, Java and so on.
Palliative (from French palliatif and Latin pallium, «pallium, cover, Greek cloak, outer garment») is a non-exhaustive, temporary solution, a half-measure that covers up the problem itself like a «cloak».
A workaround, workaround, palliative — in technical jargon a «crutch» — is a relatively quick and simple solution to a problem, applied to urgently eliminate its consequences without affecting the causes behind it. A workaround is usually a temporary or incomplete solution that does not meet the requirements for further development of the system and will later need to be replaced with a final, more complete one. Very often workarounds call for a creative approach and out-of-the-box thinking. Workarounds are used in various fields of human activity when, for some reason, a radical solution cannot be applied at all or would take too long to implement.
The main problem with workarounds is that using them reduces the motivation to solve the problem radically, and the inherently temporary «crutch» remains in place as a permanent solution, itself becoming a source of additional problems. In engineering, implementing a workaround may cause the system to fail in the future. For example, in computer programming workarounds are often used to get around a specific bug in a library. When the library is finally fixed, a workaround designed around the library's buggy behavior may cause the program to break.
During the development and debugging of a program, all sorts of errors arise. To eliminate them, so-called «crutches» are used, which make it possible to fix the bug that has appeared — temporarily or permanently — by any means currently available, despite the problems that may arise, and in most cases they do indeed arise. That in turn entails the use of yet another crutch, then a second one, and so on.
There is a saying, «A crutch props up a crutch with a crutch», and it fully describes the process of «crutch-driven development».
Code quality is unquestionably important, but if a developer is required to make corrections or add new functionality right this minute, a «crutch» may be used temporarily.
If the code accumulates a critical «crutch» mass, it is worth making sure time is set aside for refactoring.
"Crutch-driven development" in programming is a term used to describe the practice of adding temporary or inefficient solutions to program code in order to bypass or resolve problems that have arisen during development. These "crutches" are usually not clean or optimal solutions, but they can be applied to quickly eliminate errors, keep the program working, or achieve the desired functionality without rewriting the entire structure of the program.
For example, "crutch-driven development" may include the following practices:
Using global variables to exchange data between different parts of the program instead of passing arguments to functions.
Adding a large number of conditional statements (if-else) to handle different scenarios inside a single function, which makes the code less readable and harder to maintain.
Using "magic numbers" in the code instead of constants and enumerations to denote particular values.
Using crutches to bypass errors or exceptions instead of handling errors and exceptions carefully.
Duplicating code instead of creating functions or classes for reusable tasks.
Although crutches can be useful in situations that call for a quick fix, they can also lead to technical debt and degrade the overall quality and readability of the code. That is why it is important to come back to such sections of code later and consider opportunities for improvement and optimization, in order to avoid unnecessary "crutches" in the long run.
Comments