We’ve all worked on projects that struggle under the weight of technical debt. Project growth and maintenance can be hamstrung by APIs that are too abstract (or not abstract enough), by shortcuts that lead to performance problems, by a codebase that’s unnecessarily unDRY. These sorts of problems tend to become more expensive to address as time passes, as more and more code is built atop those questionable decisions made earlier in the life of the project.
Technical debt of this sort is problematic enough on a client project, where much of the end product – custom plugins and theme, choice of third-party plugins and libraries – is under the control of the developers. Things become considerably more complex when your project is a free software project, designed for wide distribution and use.
Take BuddyPress as an example. A popular plugin for adding social functionality to WordPress, BP is intended not just for plug-and-play use, but also for highly customized implementation by third-party developers. Its position in the software stack – on top of WordPress, and underneath third-party extensions and themes – makes it difficult to do *any* refactoring, much less extensive redesign.
But refactor and redesign we have! In this talk, I’ll summarize some lessons learned from the process of identifying and addressing technical debt on a project like BuddyPress. How do we define backward compatibility, both downward (with older versions of WordPress) and upward (with older versions of plugins and themes)? At what point does it become impossible to address compatibility problems in code, and how do you aggressively document changes for users and devs? How do you prioritize and strategize refactoring in a context where it’s more fun and more popular to build more features instead?
