DEV Community

Discussion on: The myth of "never going back to fix it later"

Collapse
 
stereoplegic profile image
Mike Bybee • Edited

The NASA project I worked on "went back to it later..." to turn a spaghetti codebase into an "MVC for the sake of MVC" undertaking that was, somehow, worse organized and harder to read than the spaghetti.

When things broke after Friday deploys (because of course we did them on Friday), my nagging about testing got "we'll come back to that later, we have too many features to ship" until something mission critical broke which could have killed astronauts and I stepped on toes to get testing in place.

Collapse
 
eljayadobe profile image
Eljay-Adobe

The Cycle of Misery
(by Chris Raser)

The code is "too simple to test."

The code grows.
Each change is "too simple to test."

The changes start to interact, and produce strange edge cases.
Some of these edge cases are intentional, some are accidental.
Other code is built that depends on the current, undocumented behavior.
The actual requirements are lost to time.
The code is now "not really testable."

The code has become 2000 lines of if-else chains, copy-and-pasted code, and side-effected booleans.
It has half a billion possible states, and can't be understood by mere mortals, or refactored without risk to the business.

A new feature is needed.
A bright, shiny new bit of code is created, because adding anything more to the old code is madness.
The code for the new feature is "too simple to test."