"Kintsugi is the centuries-old Japanese art of fixing broken pottery. Rather than rejoin ceramic pieces with a camouflaged adhesive, the Kintsugi technique employs a special tree sap lacquer dusted with powdered gold, silver, or platinum. Once completed, beautiful seams of gold glint in the conspicuous cracks of ceramic wares, giving a one-of-a-kind appearance to each “repaired” piece.

This unique method celebrates each artifact’s unique history by emphasizing its fractures and breaks instead of hiding or disguising them. In fact, Kintsugi often makes the repaired piece even more beautiful than the original, revitalizing it with a new look and giving it a second life.

While Kintsugi’s origins aren’t entirely clear, historians believe that it dates back to the late 15th century. According to legend, the craft commenced when Japanese shogun Ashikaga Yoshimasa sent a cracked chawan—or  tea bowl—back to China to undergo repairs. Upon its return, Yoshimasa was displeased to find that it had been mended with unsightly metal staples. This motivated contemporary craftsmen to find an alternative, aesthetically pleasing method of repair, and Kintsugi was born."

— Kelly Richman-Abdou, My Modern Met

Software applications tend to be “beautiful and clean” before they’ve been used. After interacting with the real world, they can become messy as all the edge cases, and the ugliness of reality is reflected in the codebase. Reality’s affordances get messy. At this point, a developer may conclude that the codebase has become a “legacy application,” meaning they’re unwilling or unable to make changes to it without considerable risk or cost.

A codebase that has been refactored, or “repaired” after interacting with the real world has the opportunity to be both beautiful/simple/easy to understand and correct/useful/resilient/performant. Starting from scratch repeatedly is akin to throwing away all of the wisdom accumulated in your codebase, only to make the same mistakes again.

Many teams can be intimidated or disinterested in refactoring because they may feel a responsibility to keep building features and adding new customer value. If an application has been neglected, the perceived amount of refactoring can be humongous.

Using modern tools like version control, continuous integration, containers, and plain old good written communication, it can be relatively straight-forward to gain confidence in the existing codebase, and continually/gradually improve things through the “Scout rule” (Leave your code better than you found it).

All it takes is someone to be “displeased to find that it had been mended with unsightly metal staples” and act on that.

‍