Refactoring Asteroids

Not to exaggerate or anything, but refactoring code is a lot like saving the Earth from an asteroid impact.

Asteroid (or comet) impacts have the potential to be extinction-level events, like Chicxulub impactor, more commonly known as the giant rock that slammed into the Earth and killed a whole bunch of dinosaurs.

Since we’d all like to prevent that happening to humans, NASA’s Jet Propulsion Laboratory built an interesting system they call Sentry. It scans the catalog of known near-Earth objects to find which ones have the potential to impact the planet within the next 100 years. (Note: sometimes we don’t know about these objects until they explode in the sky.)

If and when an asteroid is found that will hit Earth sometime in the future, we’ll (hopefully) begin to develop a system to deflect it away.

The good news is that if we find the object years (or decades) ahead of time, the energy needed to deflect it is relatively minor. We could fly out to the asteroid years ahead of time, give it a tiny nudge to change its course, and it will fly harmlessly past Earth when the time comes. Since the distances in space are so vast, a minor adjustment will make a big difference after millions of miles of travel.

If we wait until the asteroid is bearing down on Earth, though, the energy needed to deflect it is exponentially greater—you have to do a lot more work to change the asteroid’s path enough to miss Earth.

Refactoring feels just the same. The moment you realize a refactor is necessary is almost always the time you should address it. The required effort and the complexity of refactoring that piece in the future increases over time, until it’s too late.

We’ve all probably put off important refactors before—I know I’ve done that plenty of times. But unless there’s a strict, deadline-driven reason for a refactor to wait, always get to it early.