“Charles Darwin understood that evolution was a slow and gradual process. By gradual, Darwin did not mean perfectly smooth but rather stepwise,”1 and this was the main idea behind constructing a series of fossils through time. By showing the evolutionary steps, scientists started proving the Theory of Evolution. However, there were evolutionary gaps in the fossil records. Eaton tried to explain the gaps by “the imperfect preservation of fossil faunas and floras,”2 and this explanation has been ridiculed by Eldredge and Gould’s 1972-dated paper which introduced Punctuated Equilibria. “In punctuated equilibrium, change comes in spurts. There is a period of very little change, and then one or a few huge changes occur,”3 with a macro-mutation.

Punctuated Equilibrium 4

To a software engineer, transferring knowledge from evolutionary biology is not a grand issue. We understand and embrace change as part of our daily jobs. Refactoring is a best practice in our field and aims to evolve the codebase as software engineers gain more experience. Martin Fowler, the author of the book “Refactoring”, warns the readers that “refactoring must be done systematically.”5 He also goes further to explain that his first disciplined refactoring done by pairing with Kent Beck was “one-step at a time.”5 This sounds much like the gradual process Darwin proposed as part of the Theory of Evolution. By looking back at how the functions or classes change, we can understand the decisions behind each of those gradual changes. But then comes a point where you trace back a class and hit a dead-end. Perhaps it’s moved under a new directory, divided into subclasses, or completely rewritten. This change has certainly not been a gradual one but exemplified a spurt.

Eric Evans, the author of the book “Domain-Driven Design”, writes that “classical descriptions of refactoring sound very steady,” but “a period of steady refinement of a model can suddenly bring you to an insight that shakes up everything.”6 Fowler’s warning about the need to be systematic when refactoring holds true to this day, because refactoring is risky. That’s why you don’t go and write whole classes or modules from scratch. It’s not wise to dispose a legacy, but working system. However, when you go through a stepwise period of refactorings, you gain experience towards an enlightenment. You get a moment of spurt, an opportunity to evolve out of the legacy. If you seize the opportunity to make that huge change, your codebase becomes more likely to survive.

As with our current knowledge of the evolutionary biology, I believe we need both types of refactoring: Steady but small followed by rare but disruptive. The latter cannot succeed without the former. It is necessary to have the periods of steady refinement as knowledge crunching process. Although a small refactoring may not add anything to the domain but technical improvements, changes pile up to unlock a better understanding of the overall system. After the codebase gets out of that growth spurt, “steady refinement starts again.”

  1. Public Broadcasting Service. (n.d.). Evolution: Library: Punctuated equilibrium. PBS. Retrieved March 9, 2023, from https://www.pbs.org/wgbh/evolution/library/03/5/l_035_01.html ↩

  2. M., S. T. J., Eldredge, N., & Gould, S. J. (1972). Punctuated Equilibria: An Alternative to Phyletic Gradualism. In Models in Paleobiology (pp. 82–115). essay, Freeman, Cooper & Co. ↩

  3. Gradualism and punctuated equilibrium. New England Complex Systems Institute. (n.d.). Retrieved March 9, 2023, from https://necsi.edu/gradualism-and-punctuated-equilibrium ↩

  4. Wikipedia. (n.d.). Punctuated Equilibrium. Retrieved March 9, 2023, from https://en.wikipedia.org/wiki/Punctuated_equilibrium#/media/File:Punctuated_Equilibrium.svg. ↩

  5. Fowler, M., & Beck, K. (2019). Foreword to the First Edition. In Refactoring: Improving the design of existing code (pp. xi-xii). foreword, Addison-Wesley. ↩ ↩2

  6. Evans, Eric. (2004). Thirteen: Refactoring Toward Deeper Insight. In Domain-Driven Design: Tackling Complexity in the Heart of Software (pp. 321-326). Addison-Wesley, 2004. ↩