Can codebases be broken?
The core idea is that without war, there cannot be a peace. If country A attacks country B without declaring war, then country C cannot argue for peace because there is no war. So it is with software: software that is not broken, won’t be fixed.
What follows is a AI summary of content that I’ve put together on a question that I’m dealing with: can codebases be broken? Why ask this? Well it’s an admission of failure that can lead to surprisingly beneficial consequences, for example, that codebases get fixed.
Recognition
Recognising software as ‘broken’—characterised by unmanageable debt, excessive bugs, and unmaintainability—is crucial because accepting this state without action is a failure of discipline. Just as broken physical items are prioritised for repair, acknowledging software as broken allows teams to halt feature accumulation and focus on necessary fixes like refactoring and testing. Without this clear admission, management continues to patch issues while adding new features, leading to declining quality, especially with the addition of AI-generated code, ultimately jeopardising the long-term viability of major software projects.
Acceptance of Failure
The text argues that modern software is inherently ‘broken’ due to a perpetual cycle of updates, bug fixes, and feature additions, which creates user frustration and dependency rather than stability. It critiques the industry’s acceptance of this instability as normal maintenance, contrasting it with truly finished, feature-complete software that requires no constant updates. The author parallels this issue with the annoyance of managing numerous passwords and biometric security flaws, highlighting how users are forced to adapt to systemic inefficiencies created by developers who continuously fix their own errors. Ultimately, the piece contends that good software should be stable and complete, not reliant on endless patches.
Metric of Brokenness
The text argues for establishing a formal definition and metric for ‘broken software’ to address the hidden costs of technical debt in complex codebases, comparing this oversight to geopolitical grey zones where lack of defined conflict prevents peace. It suggests using a badge system to transparently label broken software upon release, with a proposed metric based on the number of bugs introduced in recent versions, aiming to shift focus from ‘release early and break things’ to maintaining reliable builds and improving development processes.
”Release often, break things” is broken
The text criticises the software industry’s acceptance of broken releases and continuous updates as normal, comparing it to a ‘broken fix’ cycle similar to ‘release fast and break often.’ It argues that this lack of discipline in ensuring initial software quality is concerning because it risks normalising similar errors in critical fields like medicine, where such mistakes would be unacceptable.
Constant Updates is not a sign of Quality
The text criticises the software industry’s culture of releasing buggy products and fixing them later, contrasting this negligence with fields like therapy that accept failure for growth. It argues that engineering disciplines require high standards and security proactivity to prevent data breaches and zero-day exploits, asserting that prioritising release deadlines over quality is an unprofessional attitude that needs correction.
AI: Symptom of Failure
The text argues that software quality has declined over time and that AI is a symptom of this decay rather than a solution. The author contends that relying on AI for even basic development tasks erodes fundamental understanding of problem spaces, such as servers, clients, and sessions, leading to a loss of deep technical knowledge. This trend is likened to the decline in craftsmanship seen in furniture manufacturing, where functional, disposable items replace durable, well-crafted ones. The result is a cycle of generating broken software that AI then learns from, creating a ‘race to the bottom’ that prioritises short-term profitability over maintainable, high-quality engineering.
Conclusion
Any good project manager would not argue for adding new features to a broken car, they would want to fix the car first before adding features. Why software should be any different to a broken car remains a mystery.
Comments powered by giscus
The author is available for Node-RED development and consultancy.