I took the time to write a lengthy response to a blog posting I found that asserted that Drupal couldn't be used because of the way it is coded:

This module requires that module which depends on just the right version of another module. And when you dig into to code, you just decide you’ll have to live with things or write your own module somehow. Life’s too short. I’m not hacking CMS software anymore which just has to be re-hacked to re-install the same features when the next update comes out.

Of course I think the author failed to see just how wrong this assertion is. Drupal, after all, strives to avoid the need to hack and allows modules to inter-operate with each other in a fairly loosely-coupled and highly tolerant way. Perhaps the author expected to be able to use 4.6 modules in a 4.7 installation? Who knows.

When I submitted my lengthy response on the buddhistvillage.net website, I got a page full of PHP errors complaining about tables not existing etc., and I didn't immediately see my comment appear, nor did I get a message that it was queued for moderation, so I assume it was lost. Thus, I am reprinting it here. My official rebuttal of The Spaghetti Code: Drupal Sacrilege

I have to disagree with your analysis of Drupal code and the need to "hack". The way Drupal is built, and especially the way the new Drupal 4.7 is built, you'll find very few reasons to ever change core code, even if you want to modify the way things behave. The key knowledge here is knowing the different points of entry that you have to modify the existing system. Here are some examples:

1. You want to add a field to an existing type. You can do this without hacking any of the existing files by writing a very small module that uses hook_form_alter and hook_nodeapi to first add the form element to the appropriate form and second do the CRUD and workflow operations on that extra field. Add the boilerplate hook_help and you've added your field to an existing content type in three functions.

1a. You want to change the type of form element used for a field. Examples of this would be pre-populating taxonomy or categories and making them a hidden field in a form instead of requiring the user to select them, or auto generating a title for your posts and removing the title field. Other examples could include changing a multiple select box to check boxes. You follow the same pattern as in 1 except that instead of using form_alter to add a field, you replace an existing field's widget with the widget of your choice, possibly setting the value or making it a hidden form element.

2. You don't like the way something looks. The code in Drupal that generates HTML is found in theme functions. Every theme function can be overridden in your theme, meaning you can change the way any aspect of the HTML on your site is generated without hacking anything, but rather by using the intended process for modifying Drupal.

3. Now for the cool stuff =) As you know, Drupal is capable of running arbitrary numbers of sites from a single code base. This makes upgrading multiple sites to new versions, rolling out new features, and responding to security notifications a dream. So using a multi-site setup, you want to change the way module X behaves just on one site. What do you do? If you hack Drupal core, you'll affect the behavior for all the sites you're running. The answer is to put module X in the sites directory for the site you want to alter. Take the following multisite structure:

• drupal
  • modules
    • moduleX
    • ... other mods ...
  • sites
    • site_1
      • modules
        • moduleX
    • site_2
    • themes
      • site_2_theme
    • site_3
  • themes
    • ... lots of themes ...

In this structure, Site 1 is running a modified version of moduleX. Whereas Site 2 and 3 will run the version of moduleX in drupal/modules, Site 1 will run drupal/sites/site_1/modules/moduleX. This is great because it helps you avoid ever having to hack drupal/modules/moduleX to customize behavior. You can override the whole module this way. Same goes with themes. Sites 1 and 3 can choose from all the themes found in drupal/themes, while Site 2 additionally has a custom theme available to it in drupal/sites/site_2/themes.

So I respectfully disagree that you should ever have to hack core Drupal code to get a web application that meets your specifications. At least not in common cases.