Broken Window Effect In Software Development
Consequences of Ignoring Engineering Principles: Similarities between Crime and Tech.
"The first broken window is the signal that no one cares, and so breaking more windows costs nothing."
James Q. Wilson and George L. Kelling, the authors of the theory.
A touch of idleness here and there, and before we realize it, we're engulfed in problems. This truth applies universally, impacting individuals and organizations alike. My focus today is on the ramifications of such negligence for teams and individuals in Software Development.
In 2023, I delved into the Broken Window Effect within software development, highlighting the repercussions of initially shirking immediate repairs or opting for subpar solutions. The same principles apply to strategic technical decisions.
Today, I want to focus on the negative effects again by taking into account missing Engineering principles in Software development.
The Broken Window Effect is controversial, especially since it’s a theory in criminology, but the consequences of Software Development, of not caring, are real and severe.
So let’s get into it.
What Does the Broken Window Theory Entail?
It posits that a lack of care for surroundings can lead to a gradual decline. Originally a criminology theory from 1982, it suggests that a single unattended broken window in a building signals a broader disinterest in its upkeep, leading to a cascade of neglect. This apathy can manifest in more broken windows, unchecked graffiti, and rampant littering, all indicating a downward spiral of decay.
👉 This theory mirrors the dangers lurking in project, product, or codebase neglect. Ignoring issues, delaying repairs with a "someday" mentality, and abandoning ownership and accountability can all contribute to the Broken Window Effect in a business context.
Shortcuts: A Path of Minimal Foresight
"Tolerating minor disorder leads to more serious crime and social decay."
A summation of the theory's premise, suggesting that addressing small problems is essential for maintaining social order and community standards.
Jumping to a new architecture isn't something teams can juggle alongside their regular duties.
With the launch of a new software project comes a wave of enthusiasm and the resolve to "do it right" this time. Yet, as the project progresses, daily routines erode this initial determination.
An accumulation of minor, often overlooked negatives can eventually sabotage the project. Shortcuts taken during foundational development stages, justified by the notion that "we can always fix it later," are particularly perilous. Shortcuts likely lead to shortcomings, whether strategic, operational, or coding decisions.
Choosing an overly simplistic software architecture may accelerate initial progress but at the cost of accruing technical debt. Betting on future opportunities to address these shortcuts ignores the unpredictable nature of future circumstances, such as resource availability or staffing levels. Committing to such gambles from the start necessitates a willingness to tackle the resulting extra workload—so weigh your options carefully.
🍪 I think this is the most common reason I do CTOFellowships and Mentorings. Teams often took shortcuts, sometimes without being aware of them. Only the consequences were noticed. Unfortunately, the teams often look for the wrong reasons. Engineering principles are extremely important to include in your tech culture; it’s about being aware of the process.
The Decision to Change: Technical Possibility vs. Practical Feasibility
This distinction underscores the essence of crucial business decisions over merely technical ones.
Hope-Driven Development
Hasty coding, skipping tests, or neglecting documentation are all examples of hoping for future catch-ups that may never come. From the outset, businesses must prioritize correctness over expedience.
The misconception that "doing it right" initially requires significantly more effort is just that—a misconception. The truth is that the effort to rectify mistakes later far outweighs the initial investment in quality.
Feedback from CTOs and Founders
The irony is that recent earnings for investment or new ventures are often redirected to fix past oversights.
Enduring the cycle of repaying technical debts can plunge companies into challenging periods. Blaming development teams for the resulting "mess" only exacerbates the issue, leading to demotivation and loyalty erosion. Encountering unexpected obstacles due to past decisions results in stress and overburdening.
In discussions with two tech leads in December 2022, both shared their experiences of migrating legacy applications. Whether opting for a greenfield approach or a gradual migration strategy, realizing that such drastic measures were needed just two years into the application's life span prompts a reconsideration of rushing to market.
My Insights and Recommendations
Reflect on the long-term implications of your actions and strive for sustainable strategies.
For tech leads and developers alike, prioritizing long-term success over immediate gains is essential. This approach involves strategic foresight and adherence to professional principles, ensuring satisfaction with your work in retrospect.
The Broken Window Effect Revisited
Maintaining your product's integrity from the beginning sets a foundation for lasting success.
Address issues early, choose the right foundations, and avoid shortcuts that may not hold up over time. By fostering a culture of responsibility and ownership, you mitigate the risk of falling into a cycle of debt and decline.
Ultimately, opting for sustainability over shortcuts can lead to a more gratifying and successful professional journey. What's your preference?
Key Takeaways & Insights
This condensed summary aims to reinforce the core messages for easy recall.
The Broken Window Theory
Neglecting minor issues can lead to a decline in the quality of care.
Proactive ownership and action are critical to maintaining project integrity.
The True Cost of Shortcuts
Later architectural changes are often impractical, requiring significant extra resources.
Shortcuts should be evaluated from a business perspective, recognizing their long-term impact.
Small Business Realities
Quick market entry isn't always advisable; consider the enduring effects of technical choices.
Technical debt can dominate and demoralize, so aim to prevent it from becoming a critical issue.
Personal Reflections
Plan with the future in mind, avoiding the allure of immediate rewards.
Professionalism means adhering to high standards and being proud of your work in hindsight.
Conclusion
"Fixing the broken windows is not just about the windows; it’s about restoring order, morale, and the rule of law." – Reflecting the broader implications of the theory on societal norms and expectations.
Crafting code is one thing, but engineering software is quite another. As I've often said, excelling in your personal skills is the mark of mastering your craft. Still, true engineering is about creating something more substantial—a system accessible even to those with less expertise 🍀.
I've learned, sometimes the hard way, that brilliance alone isn't enough. The real skill is devising processes and frameworks your average developer can work with and maintain effectively.
From flying solo to fine-tuning processes for the whole company
Reflecting on my evolution from master craftsman to engineer, I realize it was a pivotal transition from flying solo to fine-tuning processes for the whole company.
It was about scaling the software and creating an inclusive workspace that centers on the 'average' developer, ensuring collective success. We shifted away from the tendency of craftsmanship to over-engineer, steering towards engineering principles that value simplicity, practicality, and the ability to scale.
Being a skillful software craftsman is valuable, but it's just the beginning. Engineering goes beyond—it's about crafting a system that works and endures. It's rooted in collaboration, efficient scaling, and constructing something that benefits everyone, not just its creator. In software development, we're more than artists in solitude; we're a team of engineers banding together to push the envelope of innovation and enhance our digital world for all.
Engineering is about the long term, the process and enhancement, and the making of things easier, so the Engineers Way is the most viable way to avoid the Broken Window Effect in your teams.
Greetings from Blackforest in Germany,
Adrian