Based on what I observe going on around me, a lot of developers are constantly searching for the next new thing. Build a new app, use a new technology, write a new version of a library…you get the idea.
And there’s definitely a meaningful value to that…but deep down, I really do enjoy doing maintenance work. It’s not sexy; but it is definitely valuable.
The reality is that for any software project, there are a couple of key problems:
- If you don’t change, users will leave,
- If you change, users will leave.
You may have noticed the wee little problem with those problems.
Maintenance is a finely-tuned art: deciding when the right time is to make a change so that you can support both new, exciting environments and older environments.
WordPress obviously wrestles with this pretty much constantly. Of course it is possible to update our PHP (Hypertext PreProcessing) requirements to the latest version of PHP at any time (“possible” doesn’t mean “easy”). But the cost is abandoning literally millions of users who aren’t ready for that.
Maintenance is also the art of keeping track of what fixes are no longer necessary – like conditional scripts for Internet Explorer. It’s figuring out when new features are possible to use, and, for accessibility, figuring out when past decisions are no longer the right decisions.
Maintaining Accessibility
Accessibility is a moving target. What screen readers are capable of changes; the ARIA specifications change; browser support changes; and accessibility guidelines change.
Rian Rietveld recently reminded me that redundant entry is a WCAG (Web Content Accessibility Guidelines) violation as of version 2.2 – so email confirmation fields are now a violation of WCAG 3.3.7. I have multiple plugins that make use of email confirmations – both My Tickets and My Calendar Pro have that. It wasn’t a problem when I added the feature, but it is now.
Which means I have some maintenance to do. Hey, that’s cool. I like maintenance.
Maintenance is necessary, important work; but it is a balancing act.
When I change the email fields to no longer require confirmation, I will undoubtedly get support requests noting that the email confirmation field is missing. Some people will comment on how this is reducing the security of their systems because people don’t need to verify their email. (They’re wrong. This doesn’t influence security at all.)
Some people will comment on how they’re concerned that people will type their email incorrectly, and because they don’t have to confirm it, they won’t notice.
This is possible – but, in reality, people mostly use autocompletion or cut and paste. If there’s a mistake, it’ll probably happen in both fields.
But in this case, I’m making a change explicitly to ensure that users of the software are best positioned to maintain a high level of accessibility – so those complaints are unlikely to bother me.
Making Big Changes
The hardest maintenance burdens come when making big decisions. The difference between a single email input and two inputs is, frankly, pretty small.
But when WordPress drops support for a PHP version, that’s actually a pretty big deal. Because the sites that are still running ancient versions of PHP aren’t necessarily doing it out of choice. They may be doing it because a critical part of their business runs on some piece of software that died in 2011, and only works on PHP 5.6. They don’t have the budget to hire somebody to customize an ancient, undocumented system; they can keep running because WordPress works for them.
That’s not to say that WordPress shouldn’t move forward. It has to: the maintenance burden of supporting everything forever is fundamentally impossible. But these changes need to be carefully timed, and patiently considered.
What’s your point?
Ha! Good question. I’m fully aware that I’m wandering around in this post. But hey, it’s a blog post – it’s allowed to wander.
My two major areas of concern are accessibility and WordPress development. Both of these have constant, ongoing needs for maintenance. Code needs to be updated for the future while minimizing breakages in past implementations.
Keeping a project alive over the long term has to blend adding new features with proper maintenance of old systems.
Also, maintenance is super sexy.
Amber Hinds
I agree that there can be something deeply satisfying about helping a product evolve overtime. As you know, we chose to offload (sell/giveaway) several of our free plugins so they wouldn’t distract us on efforts to evolve our core product. Now updating documentation and screenshots… There’s nothing sexy about that.
As a side note on removing the email confirmation field, if the goal is making sure that they don’t have typos, this could probably be resolved by inserting a verification step in the form. Either something that shows all field data or just the email address and asks them if it’s correct before submitting. That might be worth doing especially for My Tickets where a financial transaction is involved.