Avoid a Race to the Bottom in Software Quality
Applying Gresham's Law to Improve Software Quality and Workplace Culture
Have you ever wondered why poor software practices tend to persist, even when everyone recognizes their detrimental effects? Gresham's law, an economic principle, provides insight into this phenomenon within software development.
What is Gresham's Law?
Gresham’s law states: "Bad money drives out good money." In simpler terms, when lower standards become acceptable, higher standards are gradually abandoned in favor of cheaper, quicker, or more convenient alternatives.
A Psychological Explanation: The Cost of "Free"
Dan Ariely, in his book Predictably Irrational, offers a psychological perspective on this law through his experiment on how "free" affects human decisions:
Scenario 1: Participants were offered Lindt chocolate for 15 cents or Hershey's chocolate for 1 cent. Most chose Lindt, clearly recognizing its superior value.
Scenario 2: Lindt remained at 15 cents, but Hershey's became free. Despite Lindt still being clearly superior, most participants overwhelmingly chose Hershey's.
Ariely’s experiment highlights our irrational attraction to "free," often causing us to prefer lower-quality options simply because there's no immediate cost.
How Does This Relate to Software Quality?
Let's translate Gresham's law into scenarios familiar to software developers and engineering leaders:
1. Code Quality and Technical Debt
Quick fixes and shortcuts become appealing when teams are under pressure to meet tight deadlines. Initially viewed as temporary, these solutions often bypass important quality measures like thorough documentation, automated testing, and well-planned architecture. Over time, these rushed solutions become standard practice, displacing better, quality-driven methods. As shortcuts accumulate, the codebase becomes increasingly fragile and difficult to maintain, ultimately creating significant technical debt.
2. Agile Methodologies and Development Practices
When poor agile practices become acceptable—such as routinely skipping retrospectives, neglecting sprint planning, or tolerating chronic antipatterns—they inevitably replace disciplined Agile or Scrum methodologies. Over time, productivity suffers, morale declines, and overall quality diminishes.
3. Workplace Culture and Performance Incentives
If an organization fails to differentiate between high and low performers, rewarding them equally, motivation for excellence diminishes. High-quality standards gradually disappear as employees see less incentive to excel.
Breaking the Cycle: Prioritizing Quality
To counteract the negative effects of Gresham's law in software development, organizations must consciously promote and reward high-quality practices:
Recognize and incentivize quality-driven developers and practices.
Establish clear standards and consistently uphold them.
Educate stakeholders about the hidden costs of shortcuts and poor-quality solutions.
Have you noticed Gresham’s law within your software teams or projects? How have you combated the race to the bottom in quality practices? Share your experiences and insights in the comments below. Let's learn from each other's challenges and successes.
Breaking the cycle, prioritize quality. One way is with rewards but they are typically short live. Unless you continuously increase the prize, they get use to it and our developpers always tend to use the shortest and easiest path.
With carrot and stick, yes the carrot can "work" but the stick is required.
But we need to be carefull. If the stick comes from management, you demotivate the team and create fear and lose creativity (plus many other stuff).
The benefit of the sticks works if it is sefl-imposed. In your chocolat example, you need to add some bad taste in the Hershey for them to learn that free is not always good.
We have some teams working in pure DevOps with multiple pushes in production per days (some per hours). Any major issues found in production goes to opsgenie and Developpers (or anyone in the team) get called, anytime of the day. That hurts!! After some experience, the teams learn and are much more carefull before pushing in prod. They increase automated coverage, start implemeting pre-prods system in Rings and much more observability in prod.
This is the best way I have ever seen in breaking the cycle.
Unfortunately we haven't found anything similar for the team working in a more traditional release of software for On-Premise systems (3- 4 months release cycles). Bugs found in pre-prod are quickly resolved and just pushed to testers or support and the Dev just goes back to work on features for the next release cycle. Showing report or dashboards on poor quality to upper management haven't made any real difference, or maybe some teams will make more effort but it's not generalize.
We have forced teams to do regular bug bashes, but Dev hates this activity and we get a "management using the stick" situation and have lost some Dev this way.
If anyone have a way to create self-impose stick, please let me know!
Thanks