Why do application developers often struggle with quality? They spend most of their time modifying code, even within an existing codebase. When I want to introduce a new feature, I must first understand how it fits into the program’s flow and make necessary changes. This requires me to analyze the data, understand its relationship to the feature, and determine any additional data I need to incorporate.
However, applications can be difficult to comprehend due to unclear logic, hard-to-follow data, or elements that only make sense to certain individuals. This is known as “cruft,” which is the discrepancy between current code and its ideal form.
One crucial aspect of quality is making it easier for me to understand how the program works, which in turn enables me to make changes more efficiently. If the program is divided into different modules, for example, I only need to examine a few hundred lines in a few modules instead of 500,000 lines of code. Effective naming conventions also assist with comprehension, allowing me to understand the code’s purpose without having to scrutinize the details. Additionally, when data follows the underlying company’s language and structure, I can quickly grasp how it relates to the request from customer support.
Cruft increases the time it takes to understand how to implement changes and raises the risk of errors. If I miss an error, it can lead to further mistakes and additional time spent on fixing things.
Cruft also impacts the future. I might find a quick method to introduce a feature, but if it entails adding cruft, it will eventually slow down the application. If the team decides to take that route, it can accumulate cruft over time, requiring several weeks of work for each change.