When I began using Drupal, I was a site builder. I could find a combination of contrib modules to do just about anything without writing a line of code. I made Views that did the seemingly impossible with crazy combinations of filters and field formatters. I built Contexts that placed my blocks exactly where I wanted them, no matter how complex the requirements.
This all changed when I began writing modules and became a developer.
You have a problem? I’ll have a custom hook, a class override, and an event listener created shortly. Custom code to the rescue.
However, owning custom code, which is what having custom code in your repo really is, is much like owning anything else that is custom. It offers the incredible freedom of building exactly what you need, but it comes at a cost.
Take a car for example. A custom car can be built exactly to your specifications with no compromises. However when it comes time for maintenance, there will be no readily available parts. No one else is trained in repairs of your car, so the local auto shop can’t help when it breaks down. Diagnosing and fixing the car is all on you. All of a sudden that generic car that doesn’t meet all your needs, but will suffice with a few modifications isn’t looking so bad.
Enough with the car analogy. Let’s examine the costs specifically related to owning custom code.
- Upfront cost to write, revise, and review the code.
- Regression tests must be written to cover the custom functionality.
- New developers are not familiar with it and take longer to ramp up.
- Documentation needs to be written, updated, and maintained.
- Security issues must be monitored and fixed quickly.
- Code must be updated when the site is migrated to a new platform.
- Compatibility must be maintained with other libraries as they are updated.
Despite these costs, custom code may still be the right answer depending on your needs. When evaluating the best approach, asking the following questions will often help.
- Are the downsides of an existing solution that doesn’t exactly meet your needs less substantial than the costs of a custom solution?
- Can functionality from an existing library or framework be extended or overridden to provide a small targeted change that limits the scope of custom code needed?
- Would a contribution to an existing module/library solve the issue and allow future development to be done with assistance by a open source community?
If after a review of all of the options, a custom solution is truly needed, adhering to the following will help minimize the custom costs.
- Strictly adhere to community code standards to make collaboration easier.
- When extending functionality, only override the methods needed to make your change. Leverage the parent class as much as possible.
- Architect code to allow for loose couplings, and leverage loose couplings when integrating with others’ code.
None of this is to say that custom code is wrong. It is often needed based upon a project’s requirements. This is simply an appeal to stop and analyze the needs at hand, instead of defaulting to a custom solution that may provide a quick fix, but come with many hidden long-term costs.
So perhaps I was on to something during my site building days by avoiding code. As a developer’s goal is not to write more code, it is to solve problems, build out functionality, and if necessary—write code. Ultimately it’s about delivering value, whether that is using existing tools, writing custom code, or a happy medium somewhere in between.
