Keeping It Real With Drupal

Some people like SNL's Stuart Smallie (OCD, child of alchoholic, and has an eating disorder) pin messages on their bathroom mirror that that are engraved with phrases such as "people like me", "easy does it". In a similar tradition, I need to pin this list of sterling advice from 37signals on my door, bathroom mirror, and the inside of my eyelid. Some of these maxims are hugely important for people working with drupal. For example:

Fight Features: Build half a product, not a half-ass product

Three State Solution: Design for regular, blank, and error states

Copywriting is Interface Design: Words are a crucial component of your UI

Many of the problems that prevent folks from adopting drupal, or 3rd party modules in particular, could be solved by following little rules like the above. However, when it comes to providing customized installations of drupal, I think these rules even become more important. I think I'll highlight a few particular one's that I think are uber important for drupal specialists in a running series of posts (this being the first):

The Customer is Not Always Right: Be willing to say no to your customers

I came from the service industry, and I rose to management before I made my daring escape. A dogma in the service industry is the customer is always right. The drupal consultant needs to shake off this dogma, and return to reality.

We are professionals because we are at the very least less incompetent then everyone else. The reason our work feeds us is because the people who pay us generally have some selfish need, but our knowledge is required before they can fufill that need (be it sales, visibility, community management, creating an illusion that they deserve a grant).

When you first begin planning the website, do your best to help them focus on that need -- and make it clear to them that you understand it. Often you will find yourself working with types that have a sort of prejudice against developers. I think they look at us as idiot savants -- geniouses of code, but too retarted to understand how a non-profit could market itself. So they throw us a tasklist, and we build it. Whenever this sort of exchange happens, the project will always defacto fail. The key knowledge we bring to the table is often not programming, but experience in using the many tools that can accomplish these goals. We know what works together, what doesn't, and how our time can be best spent. If we take on the tasklist, we've just deprived our clients of that which is most valuable: getting the most, in the least amount of time, for the least amount of money.

Goals Require Tools to Accomplish

Enabled modules are merely tools -- means of accomplishing a goal; there is never an excuse for an enabled module that has no specific goal. With that said, keep the client focused on goals, and begin recommending modules when you recognize them as proper tools to accomplishing part of their goals.

With that said... I need to get ready to drive across the state. To be continued...