Drupal's built-in flexibility and array of complicated contrib modules gives you ample opportunity to build your own unique monster if you aren't careful. Unfortunately for those who end up maintaining Drupal sites, a lot of modules and distributions don't focus much on the idea of maintainability. Instead primarily focusing on the speed and ease with which the site can be built. This may mean less up front cost, but will most definitely end up adding additional maintenance cost down the road. Site-building debt is just as real as technical debt on a traditional software project.
If you think you might be saddled with one of these beasts, I have some good news: There may still be a chance to reverse the transformation.
Monsters aren't created in a vacuum. My experience has been that there are almost always organizational issues larger than the website that help contribute to a things spinning out of control. Identifying these issues and dealing with them before you tackle the next phase of development can make the process much more productive, and spare your new team that extra chaos. You need to identify at least one stakeholder with final decision-making power and someone with the time to deal with understanding all the detailed nitty gritty of the issues on the site. In a perfect world, and on smaller projects, this can be the same person. A large committee where no member takes ownership over decisions or the results is a worst-case scenario for a successful web project.
Once organizational issues have been removed from the equation, the main thing for a site owner to start to quantify are the trade-offs between continuing to feed the monster and starting with a blank slate.
Chapter Three goes through an extensive auditing process for all of the sites we take on, but if you decide to go it alone the following questions usually are enough to trigger that 'site building smell' of a poorly built site.
Some questions to look into:
- The number of modules (particularly custom modules).
- The number of unique content types relative to how complex your content is.
- The number of users assigned to each role and the permissions associated with those roles.
- Use of complexity-adding modules like Panelizer, Context, Organic Groups, Domain especially in combination.
With a better sense of the breadth and depth of the rats nest it is crucial to re-evaluate the goals of the original project and whether they still apply. Even the largest monsters can be kept patched and secure (and locked in a dungeon) without a huge amount of effort. However if we want to build a lot of new functionality on this site we may break the bank.
Every piece of functionality (especially custom) in the current site needs to be evaluated against how it meets (or fails to meet) these original goals. The only way to start removing technical debt is by developing a better financial picture. Organizations change, marketing trends move, and website goals should change accordingly. Deleting unnecessary functionality is the most powerful tool at your disposal in a cleanup effort.
With a clearer picture of the current goals for this site and which business rules are still relevant, future efforts need to be prioritized based on what we've learned. There may be a big chunk of cleanup work necessary before we can re-start any new feature development. If new features are at the top of our list of goals, then this cleanup effort is where we should start. If we have decided to put the site on life support pending a rebuild, coming up with a clean and repeatable workflow to apply security updates and ensure stability after those pushes should be our path forward.
The bottom line is that the more organized you can be about the current state of your site the better equipped you will be to make business-driven decisions about the best path forward. As always the experts here are Chapter Three are happy to help your business navigate the path ahead.