Questioning “If It Ain’t Broke, Don’t Fix It” in Software Development

The behaviour is somewhat encouraged in Agile, with a safe net of Automation E2E via UI regression testing.

This article is one of the “Laws in Software Development” series.

“If It Ain’t Broke, Don’t Fix It” is a well-known idiom in the software industry, and many software professionals have heard it many times.

https://www.dudeme.in/products/if-it-works-dont-touch-half-sleeve-t-shirt

Source: a Reddit post, with 119K likes. (surely, many of those are programmers)

Table of Contents:
· This Idiom’s Meaning for Software Engineers
· Kaizen: “Change Good”
· Code Refactoring is an example of Kaizen
· The Missing Link: Automated E2E (via UI) Testing
· Two Stories About Changes
∘ 1. A support programmer’s suggestions for improvements
∘ 2. Optimizing database reset from ~2 seconds to 0.5 seconds
· Summary

This Idiom’s Meaning for Software Engineers

The literal interpretation of this expression is readily comprehensible. However, allow me to elucidate its implied connotations in software (as code is inter-connected).

• The software feature is presently operational without any functional issues
  Neither customers nor testers have reported defects for it.

• Changing the code (behind this feature) for enhancement might cause problems.
  i.e., Setting aside whether the new enhancement functions properly, but it may break this or introduce unforeseen issues.

• The effort, generally speaking, is not worth it.
  better to spend time and effort on others.

https://www.reddit.com/r/ProgrammerHumor/comments/1e9jity/ifitworks/

However, is this truly a universal rule, or even correct? It is valid for many teams, but not for real Agile ones. I no longer agreed with this rule in 2007, when I mastered E2E (UI) Test automation. In fact, I found significant benefits in frequently improving code that wasn’t broken. Why? Because I had the safety net of continuous testing, executing automated E2E tests daily as regression testing.

Reflections of Software I Created over the Last 14 Years in My Spare Time

Check out Kent Beck’s (Father of Agile) “test && commit || revert”.