Hell Opens Up New Exclusive Layer for Drupal Developers

(PRWeb) -- Last week, the Drupal Content Management System became the first opensource CMS to have its own layer of hell. Though many proprietary CMS's, most notably Vignette, have long had their own exclusive parts of hell, this was a first for open source.

Vincent Pendragoon, a spokesman for the Lucifer Ventures, described the new layer as a place for "Generally inexperienced, slothful, or overconfident developers who don't bother with things like APIs." When asked whether this meant hell would put a new emphasis on open source, Mr. Pendragoon replied, "Hell is merely acknowledging the amount of misery open source can inflict."

Hell's Global Marketing and Outreach team has prepared an FAQ for developer's interested in "visiting" Drupal's exclusive layer.

F.A.Q.

Q: What is drupal development hell?A: Drupal development hell is very different from other layers of hell. Most of hell is fire and ice; vipers and black widows; chains and sharp hooks. Drupal development hell is a state of mind that results from certain configurations, and certain combinations of code.

Q: How much does it cost?A: Your eternal soul.

Q: Do I have to know PHP, MySQL, or CSS to be damned to drupal development hell?A: Of course not! All parts of hell are open to everyone, regardless of age, gender, race, nationality, or education. However, our survey data indicates that drupal development hell is mostly occupied by developers, designers, project managers, or clients.

Q: You sold me. How can I go to hell? A: We thought you'd never ask. Souls are like snowflakes: no two are alike, and no two fall alike. Our marketing team has prepared a brochure for developers, project managers, designers, and clients.

A Roadmap to Drupal Development Hell
Top 10 Ways a Developer can Send a Drupal Project to Hell.

1. Be liberal in hacking the core, and hacking contributed modules. Never take advantage of drupal's theme layer. For best results, make no attempt to understand how the database and the array of includes, modules, and themes works.
2. Never search api.drupal.org for a function -- every smart person knows that there is not a single useful function in the entire api. Why use bug tested, fully integrated functions written by master programmers when you can write your own complex, one-time-one-use functions. For best results, actually -- don't use functions. And for god's sake, don't put them in a module.
3. Never use the DRUPAL-4-7 tag when checking out drupal, or modules. CVS is where the new features are!
4. Make an effort to fill up your tpl.php files with lots of scripting, sql queries, and javascript. Sure it would be easier to put that in a module, or the template.php file --but professionals should never be known for doing things the easy way.
5. At no point should you listen to the code when it fights. When the code fights, it means you need to fight it harder -- preverably with ill-thought out workarounds, and deleting blocks of code in other modules.
6. Challenge yourself -- use arbitrary names for functions, variables, css ID's and classes. One nice trick is to make different ID's, and variables use the same words, but differ in their use of underscores, dashes, capitialization, tenses, and plurality. For example, give a node the class "node-page", and wrap it in an ID "node-page", and use a switching body ID that is called "node_Pages".
7. Why build blocks within a module when you can write PHP code directly in the block? I mean, who wants to develop in a text editor?
8. Refuse to learn how the hook system works.
9. Refuse to learn how the template.php file works
10. Refuse to learn how the forms_api works.
11. Bonus: use drupal 4.6

***

Most of the time, the journey to drupal hell is a team effort. Lets go over the two most common ways a team can go to hell:

The Classic Low-Budget Rollercoaster

The most common formula is a client with big requirements and small amounts of money, and a developer who needs the work at the time. This duo is bound for hell unless, a) the client is willing to scale back their requirements to fit their budget, b) the developer refuses to sign off on the initial set of requirements, and advises a more thrifty set of deliverables.

The Red Triangle

In general, larger projects are slightly less likely to send a team to hell. This is for no reason other than large projects tending to have one, or two competent people with experience in managing developers, or clients. Contrary to popular belief, the path to hell is not paved with code, but rather with bad chains of responsibility and communication.

The red triangle refers to a forumla we've developed that brings the greatest likelyhood of a large project going to hell. The idea of the red triangle is to ensure that the project manager is defacto non-existant. In the classic red triangle flow, the client, and designer directly order the developer, and the developer is given little to no leverage to refactor, or deny their requests. For best results, treat code and development as something like "witchcraft" -- like both witches, developers have magic powers; are not to be trusted; and often will pretend they can't do something because they are lazy. Our research has found that refusal to listen to warnings from developers is the quickest way to hell.

We've provided this visual aid to help you understand the dangers of project management. Red arrows denote our recommended "red triangle", while green arrows denote paths of communciation and responsibility which may prevent you from seeing hell.

When a project goes to hell, the team will often give the developer full credit. Obviously, we disagree -- if the developer where the only one responsibile, than the entire team would not be in hell, would they? Even in cases where a developer's incompetence sends a project to hell, we feel that someone is responsibile for hiring an incompetent developer. The project manager is usually at fault in these cases. However, we also find that clients can often be given a great deal of credit, and get what they pay for. Regardless, we cannot reiterate this enough: good project managers are the single biggest block between your project and hell.

In projects that never make it to hell, the project manager should usually be the first to take the blame. At all costs, avoid project managers who: a) understand the technical challenges, and best practices of drupal development, b) are skilled at managing client expectations, c) are skilled at managing overworked developers,d) know how to ask developers questions that cut through b#llshit,e) have a sense of humor

For more information, ask your Ouija board.

Drupal version: Drupal 4.7.x