While catching up with PHP 8.2 recently, I had a chuckle at how deprecated features get top billing — as they should! Knowing well ahead of time what things that work today will break in future versions of PHP keeps developers on their toes. With the mortality of your code in view, thanks to the anticipated end-of-life of things like dynamic properties, adaptation to new and more elegant, resilient, and “correct” conventions is incentivized. Like annual growth rings in trees, this is how a programming language and community can renew itself.

That’s the gist of Brent Roose’s take on deprecation notices and Nikita Popov’s rationale for phasing out dynamic properties. Roose’s two-minute video on the evolution from PHP 5.6 to 8.2 is a brilliant and simple visual illustration of PHP’s evolution along these lines from 2014 to the present. Using the example of a simple data transfer object, Roose shows how the PHP 5.6 version shrinks enormously to a much simpler and overall more elegant block of code. 

Evolution is hard of course. The need to update legacy code causes many headaches and serious challenges. Our forward-thinking maintainers of backward compatibility in WordPress — Tonya Mork and Juliette Reinders Folmer — are concerned that WordPress developers won’t have enough time to refactor their code, not to mention the special challenges of maintaining a twenty-year-old project. Mork, Reinders Folmer, and Sergey Biryukov have been the largely unsung heroes of this daunting task for a long time.

In their discussion of Dynamic Properties and Magic Methods in PHP 8.2, Mork and Reinders Folmer point out that WordPress’s roots in PHP 3 and 4 keep it in a solidly procedural programming universe while PHP continues to advance as an object-oriented language. Core developers need to figure out a way to maintain the behavior of legacy code in today’s PHP without breaking backward compatibility “and still make the code better and more secure and mitigate the PHP 8.2 dynamic properties deprecation,” as Reinders Folmer puts it. “We are actually making our own lives very difficult with [WordPress core’s] no [backward compatibility] break rule,” she notes in the video — with a smile. 

This made me think of an old but outstanding blog post by Jeff Atwood where he discusses “The Noble Art of Maintenance Programming.” “Maintenance programming is widely viewed as janitorial work,” he wrote. I wonder if he had artist, Mirele Laderman Ukeles in mind, whose “Maintenance Art Manifesto” has always struck me as very relevant to programming and web development. They too are fundamentally tied up in traditionally denigrated maintenance tasks. 

Laderman Ukeles saw that every discipline and field of knowledge has “Two basic systems:”

“Development and Maintenance. The sourball of every revolution: after the revolution, who’s going to pick up the garbage on Monday morning? […] Development systems are partial feedback systems with major room for change. Maintenance systems are direct feedback systems with little room for alteration.”

Laderman Ukeles was a young artist and a new mother in 1969 when she wrote her manifesto and declared maintenance is art. She was frustrated with how cutting-edge works of art and high-status labor are divided from the work that makes them possible: parenting, teaching artistic skills and traditions, or just putting on an art show. She created a memorable exhibit based around herself acting as a museum janitor as people looked at the artworks on display. She spent most of her (ongoing) career as the New York City Department of Sanitation’s artist-in-residence. Her first project in that role was personally thanking all 8,500 sanitation workers “for keeping New York alive” in the 1970s.

That’s how we should treat our code maintainers too. Thank them and support them!

Atwood has a similar “maintenance art” take on programming. He quotes several major figures in software engineering who say the denigration of maintenance work is all wrong. Robert L. Glass felt “Maintenance is a significant intellectual challenge as well as a solution and not a problem,” so it ought to be regarded as an important task for the most skilled people. Joel Spolsky wrote long ago that developers are lazy, and the reason they “always want to throw away the code and start over” is that “it’s harder to read code than to write it.”

In a conversation with Andy Hunt, Dave Thomas argued, “All programming is maintenance programming because you are rarely writing original code. …. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, “I’m maintaining from day one.” The disciplines that apply to maintenance should apply globally.” Hunt agreed, “It’s only the first 10 minutes that the code’s original when you type it in the first time. That’s it.”

Atwood ultimately leans toward this viewpoint but echoes the common WordPress developer perspective that I hear from my colleagues at StellarWP like Jason Adams and Timothy Jacobs. We may always feel “behind” in a “move fast and break things” world, between the revolution of the new and maintenance of the old. But this is a good and honest place to be — very quickly everything is “old” and needs care. 

The special art of development as maintenance is a balancing act.

Laderman Ukeles is still a working artist, and a few years ago a journalist writing about her shared this story:

“When I told her that the neighborhood where I live in Brooklyn is part of the Sanitation Department’s pilot program for collecting compostable food waste, she beamed: “And do you know what that means? It means the system is backing up into your house, making you responsible. Which is what should happen— because you’re part of the system!”

What a great analogy that is for deprecation notices and maintenance programming in open source. We’re all part of the system. We can all help take out the trash or thank those who do it for us. At the end of the year and release cycles, it’s a good time to express gratitude for our best people, our maintenance artists.