Programming

Clients seem to come in sets. A couple months back, I had several clients who had hired cheap off-shore companies 12 time zones away whose developers were curiously unavailable by phone, email or carrier pigeon. You probably already know the rest of the story: client needed to spend more money to have someone else go in and try to make it all work. (BTW, always use the term "refactored" rather than "threw out" when referring to the busted up stuff the client paid for).  

Lately the theme has been clients who hired a 'Drupal developer' to do custom development and ended up with hacked up Drupal core, semi-working custom functionality and lots of odd behavior in different parts of the system. As an intelligent, hip, effective web entrepreneur, you should not strive for this.

Gumby -vs- Pet Rock

The typical LAMP application is made up of a tightly coupled set of code that all works in unison. While you may be able to configure this type of application, you cannot easily create or remove core functionality yourself. There is absolutely nothing wrong with this approach if you're developing a closed system designed to be maintained by a relatively small group of developers and whose feature set is pretty easy to anticipate and can be built in from the ground up. But this approach is not a good one for something like a CMS.

Why, you ask? Well, this is quite a coincidence as I was just preparing to answer that very question. Unlike more specialized applications (think phpbb, phpmyadmin, photo galleries, etc...), a good CMS is something that you should be able to extend, possibly in ways never imagined by the authors of the software. This type of extensibility separates applications like Google Maps from MapQuest. Like Gumby, Google Maps can be made to do any number of things never thought of by Google (from a developers perspective). And like a pet rock (did I just give away my age?), MapQuest pretty much does what it does, and if you want it to make it do something else, that's too bad, you should be using Google Maps, fool!

The contributions process for non-core Drupal themes and modules is in need of a revamp.

Currently the process is a very loose one that does not require adherence to any tagging conventions or release process. This makes it very difficult to know the status of the modules that make up a given site. I believe this probably results in many site admins out there just leaving their site as-is because the process of updating is somewhat confusing and tedious.

We want to fix this.

While there are existing 4.6, 4.7, etc... tags applied to contrib modules, they are not consistently used by module authors. Furthermore, tags are being applied inappropriately (4.7 tags applied to 4.6 code that is not actually upgraded).

This article explains a practical implementation of a technique outlined in the article "Sharing Drupal tables between databases using MySQL5 Views".

Problem

You have multiple (multisite) Drupal sites and you would like to manage the content for all of these sites through a single interface. Depending on the nature of a given piece of content, you may want the content published on one, several or all of your subsites, but you do not want to have to create copies of the same content for each site.

Solution

Taxonomy plus MySQL5 views. (NOTE: this solution will not work with versions of MySQL prior to 5.)

IMHO, the worst part of Drupal is having to learn the API. The core developers are constantly refactoring the heart of Drupal, which is a good thing overall. But it makes it very difficult for the average developer to keep up with the API. Major version releases prior to 4.7 required a developer to make relatively few changes to his module to make it compatible with the new release. 4.7, on the other hand, requires pretty much a complete rewrite of a given 4.6 module.

Drupal is as scalable as the applications it relies on. While there's nothing preventing Drupal itself from being scaled across any number of web servers, scalability of open-source databases such as MySQL and PostgreSQL is an ongoing issue. While these databases do support replication, that's not always enough. For a very small percentage of websites, daily user visits are counted not in hundreds or thousands but in hundreds of thousands.