In Part 1 of my article on The Drupal Maintenance Challenge & How to Manage It, I raised some interesting problems inherent to planning out and executing a Drupal website project. Now in Part 2, I will give some advice on how to address these challenges based on what I’ve learned in my time as a web developer.
Having a “Maintenance first” approach to planning a Drupal project
First of all, there is no silver bullet for creating a site that can fully survive an upgrade with no developer assistance needed. No one builds a site with zero contributed modules. Even if you are using some of the most popular modules in Drupal 6, you do not have a complete upgrade path to Drupal 7.
For example, CCK has a million and a half downloads at the time of this writing, and it has issues upgrading. In particular if you use CCK fields in your Views in Drupal 6, you are likely having to fix those manually in 7. And so while there isn’t a silver bullet out there, there are certain things to be aware of when planning a project that can save maintenance time down the road.
Here is a list of questions I ask when evaluating a project plan:
- For each contributed module and theme
- Does this module/theme have a stable version?
- How long has this module/theme been under development?
- What is the usage for this module/theme?
- Does this module store data?
- How critical is this functionality going to be to the site?
- How active is this project?
- For each theme
- Is this a custom theme?
- Is this a sub-theme of a well-supported base theme?
- For custom modules
- How many custom modules are there? What is the level of complexity?
This isn’t an exhaustive list but it does attempt to determine key factors that should be considered when planning out a project and its codebase. I will go through each question and its importance.
Does this module/theme have a stable version?
The first and maybe easiest factor when vetting a module is looking to see if it has a stable version.
Views Module Download Area
If the module has functionality but doesn’t have a stable module it should probably be avoided because it that scenario YOU, the developer, are likely going to be the de-facto maintainer as the module has a high risk of bugs and high maintenance requirements for the development team.
That doesn’t mean this no dev or alpha versions should be used, it just means that you should be aware ahead of time the amount of effort that will likely be required to maintain a module.
How long has this module/theme been under development?
If the module was just created a month ago you will have no idea as to its longevity, consider the risk HIGH.
Again there is an exception to every rule but every module you use with at least 1 ‘HIGH’ risk factor is likely adding more maintenance time to the project over the life cycle of the site.
What is the usage for this module/theme?
If the usage is very high then the risk is going to be much lower that this will be unsupported in the future. This is not a silver bullet either as there were popular modules such as Ubercart and Content profile in Drupal 6 that do not have a clean upgrade path.
Panels Module Download Information
That being said, there is enough community support that there are people attempting to create ‘upgrade modules’ for either project as is often the case when a popular module doesn’t get upgraded to the next version. So at least you are not up a creek by yourself.
Does this module store data?
This is not always obvious, but you can usually get some kind of an idea from the module description. For example if this module provides a new ‘Field’ type, obviously it is going to store that field data somewhere.
Modules that don’t manipulate data have less ‘maintenance’ risk than modules that do. For example if you install the ‘admin’ module and get tired of it you can throw it away for another module. That is not the case for Panels, Views, Organic Groups, etc..
How critical is this functionality going to be to the site?
A module that adds a twitter button to each post will have generally low risk.
A module that extends Organic Groups and integrates it with other content on the site to create functionality that is crucial to the business goals of the site will need to be vetted more thoroughly. You should be very sure that a module that provides a substantial piece of functionality scores well in the other areas mentioned.
How active is this project?
If the module hasn’t had a release in a year that is a big red flag. Some modules reach maturity and stop adding new features but still maintain fixes, etc.. That is not necessarily a bad thing. It is a judgment call, but some modules should be completely avoided. If there hasn’t been a stable release in a year, for example this is probably a module that YOU, the developer will be maintaining.
Is this a custom theme?
The risk is pretty high that you will be completely redoing the theme, as the theme layer tends to go through a lot of changes from version to version. I don’t know in Drupal 6 what someone could have really done to prevent a theme overhaul in Drupal 7 when coding a custom theme.
I would presume the same scenario for Drupal 8, so it is just something to be aware of. If it took 60 hours to create a theme in Drupal 7 from scratch, then even without a new redesign I will take nearly 50-100% of the same amount of time to upgrade in my opinion.
Is this a sub-theme of a well-supported base theme?
The risk will be much lower the more you rely on the base theme which likely will be upgraded for you when the next version of Drupal is released.
There are certainly no guarantees and even base themes will change from version to version but the idea behind a base theme is that the subtheme ends up usually having a much smaller footprint. This makes that theme not only easier to manage, but easier to upgrade.
This has been my experience with for example, the Fusion base theme. It did have some very significant changes when it moved to the 2x version for Drupal 7. That being said I have found that it is still easier to upgrade a Fusion subtheme on average than it is to upgrade a custom theme if for no other reason than the subtheme is usually half the size or less (i.e. in number of files, customizations, etc.).
How many custom modules are required? What is the level of complexity?
Custom modules will likely need to be upgraded manually using a module like the Coder module to help developers easily find hooks/code snippets that have changed in the next version.
You can look at each module and determine whether or not the level of complexity will likely make it a higher risk for additional maintenance time.
Assessing a project’s ‘Maintenance Risk’ as a whole
I have spent some time detailing several questions that I ask myself, as a developer when I am scoping out a new project. That doesn’t mean I spend hours of time researching 100 different modules. That is because I already have 20-50 modules I end up using for every project that I know the maintenance risk for (see my top 50 modules list). So depending on the size of your project, the list of modules might actually be as low as a couple dozen (or even fewer) that you need to research.
As a good mental exercise it might be a good idea to sort through how many modules/themes are in the ‘low risk’ area of your venn diagram, how many are in the ‘high risk’ and how many fall between. The idea is to have an honest assessment to the level of ongoing maintenance that will be required to keep this project stable and in as good of shape as possible when the next Drupal version is released.
Here is an example of a Venn diagram I threw together to illustrate this point.
Venn diagram for an example project
This list is somewhat subjective and merely for illustration. I put several popular modules on the right side that I use on almost every project. I placed a few in the middle that are also popular but maybe ones that I have had some maintenance issues with in the past. On the left I placed an example custom module and a handful of other modules that only have dev versions at the time of this writing.
And so what you gain by using this exercise is some perspective on the level of effort that will be required to maintain this project into the future. While this may seem obvious I think ‘maintenance’ cost often gets overlooked. The reality is that developers add modules to the scope of a project that solve a needed business problem without weighing the long-term costs for that module which may not be well supported. If you do this over and over again, you create a project that cannot be sustained easily throughout its life-cycle.
Takeaways for a ‘Maintenance First’ Approach
We know that there are challenges for supporting a Drupal-based website that contains code from literally thousands of independent developers across the world. Drupal’s modular framework allows modules to coexist and complement each other but not without risk. One module or core update can break another. A new feature can introduce new bugs. This is an ongoing problem with no easy answers.
My point is that developers and project managers can have a more systematic approach to assessing risk when planning a new project or new feature to an existing project. Asking simple questions ahead of time like ‘how long has this module been under development’ can save loads of time in the future in developer costs.
Having an honest assessment and communicating that to the client will help clients have a realistic understanding of how much maintenance risk is associated with their website. And when clients understand this, they can make better informed decisions. When clients are informed, they can better decide about which feature can be scrapped or reworked to lower the risk of problems or higher development costs down the line.