Deep down, I love maintenance  ## Metadata - Author: [[Joe Dolson]] - Full Title: Deep down, I love maintenance - Category: #articles - Document Note: --- tags: - #wordpress - #accessibility - #open_source Author: Joe Dolson Source: Personal blog Reference: https://www.joedolson.com/2025/09/deep-down-i-love-maintenance/ date created: 2025-09-09 00:00 --- # Title: Deep down, I love maintenance ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references-1) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis Prompt](#-darvo-analysis-prompt) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - WCAG 2.2, Success Criterion 3.3.7 Redundant Entry - ARIA specifications and browser/screen reader support (general references) - WordPress PHP version support policies (general references) ## 📝 Summary: Joe Dolson argues that software maintenance—especially in open source and WordPress—is undervalued but essential. He frames maintenance as a balancing act: if you don’t change, users leave; if you do change, some users also leave. He highlights accessibility as a moving target due to evolving screen readers, ARIA, browsers, and WCAG updates. A concrete example is WCAG 2.2’s Redundant Entry criterion (3.3.7), which makes email confirmation fields nonconformant; his plugins will need updates. He contrasts “small” changes (removing a duplicate email field) with “big” ones (dropping PHP versions), noting the ethical and practical impact on users with constrained budgets and legacy systems. The thesis: long-term project health blends new features with careful, empathetic maintenance—and yes, “maintenance is super sexy.” ## 📖 Main Content: Dolson challenges the industry’s fixation on novelty. While new tech has value, he celebrates maintenance as the art of timing, compatibility management, and deprecation hygiene. In WordPress, updating to the latest PHP is “possible” but not simple; it risks excluding millions on older stacks. Accessibility exemplifies maintenance-as-process: technologies and standards shift, so past correct decisions can become wrong over time. - Maintenance as balance: - Change too little: stagnation and attrition. - Change too much: breakage and abandonment. - The craft: supporting both “new, exciting environments and older environments.” - Accessibility maintenance: - Evolving targets: screen readers, ARIA, browsers, WCAG. - WCAG 2.2’s Redundant Entry (3.3.7) now makes email confirmation fields a violation. - Anticipated pushback: perceived “security” benefits or error reduction—countered by evidence of autocomplete and copy/paste leading to identical mistakes across both fields. - Scope of change: - Small: swapping out a field pattern. - Big: dropping PHP versions, which can strand organizations running critical legacy software. - Principle: - WordPress must move forward; supporting everything forever is impossible. But changes should be “carefully timed, and patiently considered.” - Long-term sustainability requires blending new features with steady maintenance. ### 🗒️ Notes - Industry culture: - Many devs “search for the next new thing.” - Novelty ≠ value; maintenance is valuable though unglamorous. - Paradox of change: - “If you don’t change, users will leave; if you change, users will leave.” - Implication: decision-making must weigh timing, impact, and communication. - WordPress realities: - Updating PHP requirements is feasible but costly in user impact. - Millions depend on older environments; maintenance is stewardship. - Accessibility dynamics: - Tech and standards evolve; “past decisions are no longer the right decisions.” - Email confirmation fields now conflict with WCAG 2.2 (3.3.7). - Anticipated objections: - Security concern: incorrect—confirmation fields don’t affect security posture. - Error concern: potential, but in practice autocomplete/copy-paste reduce the benefit of a second field. - Change taxonomy: - Minor UX config vs. foundational platform dependencies. - Big changes require empathy for constraints (e.g., budgets, legacy systems). - Guiding philosophy: - Move forward, but not rashly. - Blend features with maintenance for longevity. - “Maintenance is super sexy.” ## 📖 References: - WCAG 2.2, SC 3.3.7 Redundant Entry - ARIA Authoring Practices Guide (for evolving patterns) - WordPress core PHP support policies and servehappy project - Screen reader release notes (NVDA, JAWS, VoiceOver) for capability changes ## 🗣️ Paraphrase: 1) Original idea: “If you don’t change, users will leave; if you change, users will leave.” Paraphrase: Regardless of whether you stand still or push forward, you risk losing users; the real skill lies in choosing when and how to evolve without abandoning your base. 2) Original idea: “That’s not to say that WordPress shouldn’t move forward… these changes need to be carefully timed, and patiently considered.” Paraphrase: Progress is necessary—perpetual backward-compatibility isn’t feasible—but upgrades must be paced and planned with care, acknowledging the real-world constraints of dependent users. ## 📰 Newsletter: This week in WordPress and open source, we’re spotlighting maintenance as a superpower. While shiny new tools grab headlines, the real wins often come from thoughtful upkeep: improving accessibility as standards evolve, pruning outdated patterns, and timing platform upgrades to minimize disruption. Learning web development? Start with empathy-driven fundamentals: progressive enhancement, semantic HTML, accessible patterns, and version stewardship. Recent updates worth noting: - Accessibility: WCAG 2.2’s Redundant Entry (3.3.7) means double email fields are out—favor single inputs with clear validation and confirmation flows. - Platform health: Keep an eye on PHP version deprecations. Plan upgrades with staging, tests, and communication playbooks to support clients on legacy stacks. Community highlights: - Case studies from teams modernizing legacy sites while preserving business-critical workflows. - Contributor sprints focused on accessibility regression fixes and documentation improvements. New and notable plugins: - Form plugins emphasizing WCAG 2.2 compliance. - Maintenance utilities for dependency scanning and PHP compatibility checks. Want to go deeper? Read Joe Dolson’s reflection on why “maintenance is super sexy,” and join the conversation on sustainable, user-centered progress. ## ✅ Action Items: Strategic prompt for alignment with your role and goals: - Framing: Explain how maintenance-focused writing reinforces open-source advocacy by valuing stability, inclusivity, and long-term stewardship. - Contributor engagement: Map concrete on-ramps (e.g., accessibility audits, deprecation cleanup, PHP compatibility testing) that welcome first-time contributors. - Education: Translate evolving standards (WCAG/ARIA) into curricula, workshops, and checklists. Provide example diffs for pattern changes (e.g., removing redundant email fields). - Sustainable funding: Tie maintenance to funding narratives—maintenance reduces risk, supports small orgs, and merits budget lines for ongoing work. - OSPO trajectory: Position maintenance metrics (mean time to update, compatibility coverage, accessibility conformance) as program outcomes. Propose policies for deprecation timelines and stakeholder communication. - Transparency and inclusivity: Publish change rationales, migration guides, and clear sunset schedules. Invite feedback from impacted segments (e.g., sites on older PHP). - WordPress ecosystem: Advocate phased rollouts, feature flags, and back-compat shims; foster cross-team collaboration on accessibility and PHP upgrades. - On/off stage: Combine talks, live coding, and written guides showing step-by-step maintenance plans, testing matrices, and user impact assessments. Use this as a standing rubric to analyze each article’s relevance to open-source advocacy, contributor nurturing, and your OSPO leadership goals. ## 🧪 Hypotheses: - H1: Removing redundant email confirmation fields reduces friction without meaningfully increasing invalid email submissions in production. - H2: Clear communication and phased deprecation schedules reduce user churn during major platform upgrades (e.g., PHP version drops). - H3: Accessibility-focused maintenance yields measurable increases in task completion and reduces support tickets over time. - H4: Organizations on legacy PHP maintain WordPress sites longer when provided migration tools and funded upgrade pathways. ### 📊 Methodology: - Design: A/B test forms with and without email confirmation across varied user cohorts; measure error rates, completion, and support contacts. - Data sources: Analytics funnels, support ticket tagging, plugin telemetry (opt-in), user interviews from legacy-constraint orgs. - Analysis: Difference-in-differences for pre/post changes; survival analysis for site retention post-deprecation; qualitative coding of user feedback. - Tooling: Lighthouse, axe, Playwright tests, PHPCompatibility scans, WordPress automated testing (PHPUnit), and synthetic monitoring. ### ❓ Questions: - What communication cadence best reduces anxiety during breaking changes? - Which accessibility changes yield the highest ROI in real user metrics? - How can we quantify “maintenance value” to justify funding? - What migration incentives help resource-constrained orgs modernize? ### 🔮 Future Research: - Longitudinal studies on accessibility maintenance and user satisfaction. - Economic impact models of deprecation on small businesses. - Standardized back-compat scorecards for plugins/themes. ### 💡 Implications: - Evidence-backed maintenance planning can inform WordPress core policies, improve plugin marketplace quality, and guide OSPO governance on lifecycle management and inclusivity. ### 🧠 Learning Styles Assessment: Readability: Plain-language blog post; likely 9th–10th grade level. - Visual (Spatial) - Present: Textual structure with headings. - Improve: Add diagrams of deprecation timelines, flowcharts for accessibility decisions. - Aural (Auditory) - Present: None. - Improve: Provide audio narration or short podcast summary. - Verbal (Linguistic) - Present: Clear, conversational explanations and examples. - Improve: Add analogies and links to standards and migration guides. - Physical (Kinesthetic) - Present: None. - Improve: Include step-by-step exercises (e.g., remove an email confirmation field and test with screen readers). - Logical (Mathematical) - Present: Reasoned trade-off framing. - Improve: Add data, metrics, and decision matrices. - Social (Interpersonal) - Present: Community-oriented context (WordPress). - Improve: Link to forums, Slack channels, contributor sprints. - Solitary (Intrapersonal) - Present: Reflective tone. - Improve: Add self-audit checklists for projects. - Naturalistic - Present: None. - Improve: Use sustainability metaphors (maintenance like ecosystem stewardship). ### 📊 Accessibility Assessment: - Screen Reader Compatibility: Likely good if semantic HTML is used; article discusses accessibility awareness. - Improve: Ensure headings hierarchy, landmark roles, descriptive link text, and alt-text for any images. - Keyboard Navigation: - Improve: Confirm focus order, visible focus indicators, skip links. - Contrast and Readability: - Improve: Test with WCAG AA contrast; allow reader mode and prefers-reduced-motion. - Text Resizing: - Improve: Verify reflow at 200–400% and responsive typography without clipping. ### 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - Cultural Relevance: - Present: Focus on accessibility and users with constraints. - Improve: Include examples from diverse org sizes, languages, and regions. - Inclusive Language: - Present: Neutral and respectful. - Improve: Define acronyms (WCAG, ARIA) inline and avoid jargon without context. - Neurodiversity Support: - Present: Short sections and headings. - Improve: More bullet points, summaries, and predictable structure. - Representation: - Improve: Add case studies highlighting varied identities and socioeconomic contexts. - Psychological Safety: - Present: Empathetic tone. - Improve: Provide content notes for potentially sensitive topics (e.g., resource constraints) and invite respectful dialogue. ### ✅ Logical validity: - Positive reasoning: - Causal reasoning: “If you don’t change… if you change…” highlights trade-off dynamics; strengthens by acknowledging reality on both sides. Could be enhanced with retention/churn data. - Balanced view: Advocates progress while recognizing limits of eternal back-compat; suggests careful timing—nuanced and ethical. Enhance with decision criteria (usage %, security risk, maintenance cost). - Coherent counterarguments: Anticipates objections about security and typos; rebuts with realistic usage patterns (autocomplete/copy/paste). Improve with empirical error-rate comparisons. - Ethical reasoning: Recognizes impact on resource-constrained users; supports patient rollout. Could add mitigation strategies (LTS, shims, funding). - Potential weaknesses: - Hasty generalization risk regarding email confirmations and security; strengthened by citing WCAG 2.2 and clarifying security model, but would benefit from data. - Appeal to intuition about user behavior; suggest instrumentation to validate. Tone of voice: Conversational, reflective, pragmatic, and empathetic; mildly humorous (“maintenance is super sexy”). 🔍 DARVO Analysis Prompt - Deny: Not present. The author does not deny problems; he acknowledges maintenance burdens and accessibility updates. - Attack: Not present. No personal attacks or defamation; anticipates user feedback respectfully. - Reverse Victim and Offender: Not present. The piece does not cast maintainers as victims; it advocates empathy for users. - Notes: Tone is conciliatory and solution-focused. No DARVO tactics or manipulative framing detected. ### 🔍 SEO Evaluation: - Keywords: - Likely targets: “software maintenance,” “WordPress,” “accessibility,” “WCAG 2.2,” “PHP version support.” - Improve: Ensure primary keyword in first 100 words and in H2s; add long-tail variants (“WordPress maintenance strategy,” “WCAG 2.2 redundant entry”). - Meta Description: - Improve: Add a 150–160 character description including “WordPress maintenance” and “accessibility.” - Title Tag: - Current: “Deep down, I love maintenance.” - Improve: “Why I Love Software Maintenance in WordPress (and Accessibility)” to add keyword clarity and stay within 50–60 chars. - Headers: - Present: Section headers exist. - Improve: Include keywords in H2s—e.g., “Maintaining Accessibility in WCAG 2.2,” “WordPress PHP Support Trade-offs.” - Content Length: - Moderate length; valuable but brief. - Improve: Expand examples, data, and links to resources. - Internal/External Links: - Improve: Link to WCAG 2.2 Redundant Entry, ARIA docs, WordPress PHP support, and related posts. - URL Structure: - Good: Short and descriptive with “maintenance.” - Image Optimization: - If images exist, ensure descriptive alt text, optimized filenames/sizes. - Mobile Optimization: - Likely responsive; verify Core Web Vitals and page speed. - User Engagement: - Improve: Add calls to action for discussion, related posts, and code examples. - Schema Markup: - Improve: Add Article schema; consider HowTo/FAQ if adding structured sections. - Social Sharing: - Improve: Ensure Open Graph/Twitter Card tags with compelling summary and image. ## 🎯 Conclusion: Dolson’s central message: maintenance is essential and worthy of enthusiasm. In WordPress and accessibility, the craft lies in timing, empathy, and steady evolution—removing outdated patterns like email confirmations per WCAG 2.2, while planning major shifts (like PHP deprecations) with care for users’ constraints. Sustainable open-source thrives where new features and disciplined maintenance meet, guided by transparency, inclusivity, and a bias toward long-term health. - Summary: What is it about software maintenance that makes it interesting? Why should we love software maintenance in open source software? - URL: https://www.joedolson.com/2025/09/deep-down-i-love-maintenance/ 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: 1. If you don’t change, users will leave, 2. 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](https://www.trylon.org/wp-admin/post.php?post=193027&action=edit). 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](https://rianrietveld.com/) 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](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry). I have multiple plugins that make use of email confirmations – both [My Tickets](https://www.joedolson.com/my-tickets/) and [My Calendar Pro](https://www.joedolson.com/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., Deep down, I love maintenance, Joe Dolson, 01k4n6fj8jmty70p62pk5dw4sb.