You never touch the good code, that’s why all code looks bad
Most software in business doesn’t solve inherent difficult problems. While some complexity is unavoidable, it can mostly be reduced by breaking down and understanding problem better. However, this is easier said than done. Redefining a problem often requires a deep understanding of both the domain and the technical aspects, which is often where developers struggle. Lack of problem understanding makes for complex solutions.
Another issue is the loss of knowledge over time. In many cases, the original developers who understood the nuances of the codebase may have moved on, leaving behind code that is difficult for others to interpret. The knowledge to determine whether a piece of complexity is essential or not is often lost. This results in code that appears unnecessarily complicated because the rationale behind its design is no longer clear.
Deciding whether a particular aspect of the code is necessary or can be simplified often requires an authoritative figure who understands both the business and technical domains. Unfortunately, such authority is not always present. In some organizations, neither the customer nor the product owner has the requisite knowledge to make informed decisions about the code. This indecisiveness can lead to the accumulation of technical debt and code that looks bad.
While it may seem that software code is always bad, it is crucial to understand the underlying factors contributing to this perception. Essential complexity, loss of contextual knowledge, and the absence of clear decision-making authority all play pivotal roles. By acknowledging these challenges, teams can work towards improving their code bases and making them more maintainable and understandable.