Celebrating the nature of repaired software.

May 28, 2020
Ryan Findley, Principal
Philadelphia, PA
"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.

Recent Blog Posts

March 11, 2020
Cleaning up other people’s messes is a growth industry
People are increasingly choosing not to start from a blank slate, but to start from something good (or, in some cases, something just okay, or even bad) and make it into something great. 
March 11, 2020
"This code is terrible, we have to start over"
One crucial-yet-rare skill needed to prevent a codebase spiraling into “legacy” status is developer empathy.
March 11, 2020
Have confidence in your critical applications
​Developed by a moon-lighter, built by a team that's no longer involved, or stewarding open-source contributions, get confidence in your application.
April 14, 2020
COVID-19 Announcement for Existing and Prospective Clients
Please do not hesitate to reach out to me directly if you have any questions, concerns, or ideas for how to make this sudden and unexpected transition to remote work go more smoothly for your team.