Technical debt in WordPress
Technical debt. We don’t hear much about it outside of development circles. But it’s an important concept that all stakeholders need to be aware of. It’s the idea that a series of poor fixes cost more over time than doing it right the first time.
When used in the enterprise, WordPress has a tendency to carry a good amount of technical debt, and this is one of the main factors that leads clients to their initial engagement with us. What can we do to mitigate this tendency at the enterprise level? How can we clean it up when it happens? The first step is to understand how technical debt specifically occurs in WordPress.
At the core, WordPress is a general purpose blog software, largely built without a modern object oriented structure. Because of its ubiquitous and general purpose nature, plugins exist to add any amount of functionality to it, from community management, to e-commerce. However, the legacy procedural nature of WordPress can work to its disadvantage when developing new functionality.
This dissonance between what the platform was originally intended to do, and the specific use case that it may actually be used for, can force developers to make compromises when developing or adding functionality. Combine this dissonance with a procedural codebase that does not strictly enforce an API for extending functionality, and you’re setting the stage for technical debt to creep in.
Additionally, the quality of WordPress development services currently in the marketplace are of an extremely variable quality. The low barrier of entry to WordPress is a double–edged sword. It has made WordPress ubiquitous, but it also can encourage fledgling developers and agencies to oversell their skill level. A developer who lacks experience can generate technical debt in a WordPress application at an alarming rate.
How does technical debt manifest?
Technical debt manifests in several ways. It can creep in over time, slowing down development efforts and causing site operations to stagnate. Some of the warning signs we see from a stakeholder and user perspective are as follows:
- Excessive development time for visual changes
- High system resource usage
- Inconsistent theming
- Bug reports that reoccur or return on update
- Updates that break site theme
- Developers unable to update the website to the latest version of the WordPress core
As a site owner or stakeholder in charge of any WordPress site, if you are experiencing any of the symptoms above, stop any ongoing development, and obtain a full review of the current codebase, as well as any in-house development practices.
How do we remediate and prevent technical debt?
At Curious Minds, we’ve developed a methodology for the prevention and remediation of sites that are experiencing technical debt. Even extreme amounts. Our focus is clearing technical debt from codebases in our care, and creating maintainable and enduring sites for our clients. Roughly 85% of sites in our care were originally in a distressed state. How do we return these sites to a stable condition?
As part of our standard client on-ramping, we perform an automated static code analysis. Basically, we use a series of algorithms to review a copy of the code, and score it to a set of standards. We use this scoring to identify trouble spots in the application; places where our developers need to look. Many times, these trouble areas that are identified in the automated code review directly correlate to the functionality bugs that the client is experiencing.
Most clients have ongoing marketing and development schedules that can’t be paused for a comprehensive site refurbishment. In our methodology, we blend and prioritize client requests alongside the refurbishment efforts. During our on-ramping consultation, we build a comprehensive project plan that balances both requirements.
Preventing the accumulation of technical debt during ongoing development efforts can be the subject of its own blog post, but here, we can cover the basics. Our studio attacks the issue with a combination of investment in individual developer skills, combined with strong organizational coding standards. We back this up with the same automated code review process used during our on-ramping process on the code created. That way, any glaring issues can be dealt with before going into production.