When life gives you bad role models, make rolemodelade.
We learn so much in life from the mistakes of others. Can a best practice really be identified until a worst practice comes along that makes us laugh and cry?
Drupal's flexibility allows endless possibilities to mangle sites. The Drupal "Clean Up and Rescue" job has become all too common. This unforeseen "additional phase" occurs when a client has to hire a new team to fix what a less experienced team built. By fixing all the worst practices in site architecture and coding that destroy the performance, security, maintainability, stability, and functionality of botched Drupal sites, valuable best practices and "what not to dos" emerge.
In this session I'll cover some of the most common ways I've seen Drupal projects botched and what it takes to both fix them in your clean-up work and make sure you and your team never make these mistakes. It will focus on site architecture, site building, and custom module development do-not's and do's.
This session is also submitted for Drupalcon CPH: http://cph2010.drupal.org/sessions/learn-worst-lessons-taken-drupal-rescues
Comments
including how to spot one *before* taking on the project?
Some discussion of managing client expectations when they've already spent most of their budget on the manglers would be terrific. How do you break it to them gently that they need more than a few hours of finishing touches? That might be another session.
Jean Gazis
www.jeangazis.com
www.webhostny.com
Probably another session for that aspect
I think this session...
http://groups.drupal.org/node/70988 (especially the "How to deal with crazy people" part) ;)
...will cover that aspect more.
If you're interested in
If you're interested in co-presenters, I could think of a list of people with plenty of fixer-upper experience. :D
this might make a good panel
I had suggested something on what to look out for when taking over a project mid-stream, and someone else responded that it would make a good panel. Could we get 3-4 people to talk on this, with audience discussion?
I don't feel that I am expert enough, but I've had a couple of experiences where it seemed clear to me that things were very bad, but I couldn't tell exactly how bad... I suspect the line between a great challenge & learning opportunity and "be afraid, be very afraid" is sometimes very fine.
Jean Gazis
www.jeangazis.com
www.webhostny.com
I'll volunteer for a panel...
I've rescued quite a few badly broken sites, sadly.
Knowing how to pick apart the knots is the hardest part... Coders who don't get 'Drupal' end up hacking to make it 'do what they want', meaning you often need to 're-Drupal-ize' someone's mistakes before you can move forward with anything else.
That would be a great topic,
That would be a great topic, I'm working on a huge project now to refactor/repair a site built by an Indian shop (they got what they paid for), I could give you material if you need more...
Great topic
This couldn't come fast enough. You may also want to talk specifically how level of experience affects architecture. At what point do people really appreciate the nuances of a scalable Drupal architecture? I was on a call with one person who thought only 20 people in the world really knew how to scale drupal to 1M+ unique user site. What types of mistakes with someone with 2 years experience make? 5 years? etc. How do you mitigate these mistakes with a mix of team experience? I look forward to the talk.
(I posted this on a parallel
(I posted this on a parallel dicussion for the Freelancing session, but it makes more sense here.)
I wonder if, as part of this presentation, we could collaboratively come up with some guidelines that clients can use to judge the quality of prospective developers they want to hire. We could explain them in the context of "we've had to repair this, here's how you prevent it in the first place," and make a document that people can use.
I'm not sure how to make guidelines like that for non-developers to use, however. Any thoughts?
still useful for non-developers
I am not a developer, but I've seen a site where, for example, there were no roles set up other than the defaults of "anonymous" and "authenticated" and access was controlled by simply removing items from menus. I'm not a programmer and don't know PHP, but I'd bet good money that core was hacked, without having to look at it, because clearly the people working on it do know how to make code, but don't know Drupal.
There are probably some common "red flags" that can be spotted without looking deeply at code. What is difficult sometimes is knowing whether something non-standard was done for a good reason (since there often are multiple valid ways to achieve a result), or out of ignorance.
Jean Gazis
Jean Gazis
www.jeangazis.com
www.webhostny.com
Only 2 roles is a good red
Only 2 roles is a good red flag... another one I'd add (from the project I'm working on now) is every page being a node with a php include() to an external file. Every list, block, and pane was done that way, so it looked like Views was running but it wasn't actually doing anything!
Or (following from that one) if the custom code your developers have created is filled with dozens of very long SQL queries... unless they're working with some crazy non-node data model, that's likely a sign that they didn't use any of Drupal's APIs.
Or if the site has a custom design but there are less than 3 .tpl.php files in the theme... or if it has a custom design but the only theme running is Garland (hacked). There are so many ways to do it wrong!
There's a module called Hacked! which is supposed to check if your modules have been hacked, I haven't tried it (I've used my own shell scripts to do that in the past) but every client should run it once (on the staging site if possible) to see what their developers have done.
Great topic
Any chance that you'll be willing to post the presentation for those of us not able to make it to DrupalCampNYC8?