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.

image credit: https://www.idioms.online/if-it-aint-broke-dont-fix-it/

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/