I’ve finally wrapped my head around the blocks, views, and content construction kit model for Drupal, which we’re going to be using for the upcoming relaunch of the Poughkeepsie Farm Project website (you can see the work in progress here). It took a number of days to make a mental breakthrough that let me understand what it was that Drupal wanted me to do to get results. The big break through was getting that custom content types is really what I wanted and then how to use views to display them correctly.
The exercise was one of programming with constraints. As a veteran software developer, I’m used to getting a blank page where I can happily build up features from scratch. That has the advantage of the end product doing exactly what I want, but has the disadvantage of having to do everything from scratch. While from scratch is often satisfying, it’s also often really tedious. By the time you’ve written your 3rd password reset system for a web application, you’ll feel that way as well. Life is too short to keep repeating yourself.
The alternative is something like the drupal approach. Start with a lot of the application done, and just complete the pieces you need for the project. As a veteran software developer, I’ve been there too. I’ve come into many a project late in the development cycle, and had to work inside the constraints that are already there because of decisions made in the past. These decisions might have been based on money, expertise, timing, politics, or any number of other reasons. At the end of the day it doesn’t really matter, you just have to accept what is, and figure out how to work with it.
Building on top of a framework like Drupal is like being brought in late on a project, where the rest of your team is the drupal community. They made decisions on how things will work, and you just need to figure out what those were, and if you can work constructively inside those contraints. It’s a different skill than the “from scratch” skill, but is just a valuable. The real world has a lot more half finished projects out there than blank slates.
People love to complain about frameworks, especially tech folks, because they feel the constraints are hampering their productivity. As any tech person knows, when you switch up what you are working on substantially, you go through the “wow I’m stupid” phase again. Your output suffers, and you feel like you are never making any forward progress. It takes weeks to months to get familiar enough with the new skill set, and actually start creating anything of value. No one likes to feel stupid, so a very standard reaction is to lash out at the tools, say they are the issue, and go back to your comfort zone. You get a lot of hating in tech on exactly that. But not all frameworks or tools are bad, and writing things off as evil because you never invested the time to understand how they work are as silly in web frameworks as they are with compound miter saws and belt sanders.
At some point in the next couple of months I’m going to write up my own “getting your head around drupal” blog post, because I have to admit I did it by brute force. Eventually I got enough insites to start getting productive. It took a while. I’ve been actively working on the farm site since september, and did a whole drupal layout back in the sprint just to kick the tires. But overall, this was definitely worth it, and I’m quite happy with the output levels I’m getting now.
It's always more complicated 