[consulting] Cleaning Up After Bad Developers

[Roshan Shah]

50% of the projects we take on were started by other developer who in most
cases was new to Drupal and doing Drupal Development for the first time.

We find implementation issues in most cases and when Drupal core is hacked,
it becomes extremely difficult to understand why hack was done because when
the customer brings the project to us, the relationship with previous
developer is not healthy and there is no documentation provided.

I think partly its a problem with Drupal(underlying PHP itself). I keep
saying to my team that we always get 95% of the site done quickly but the
final 5% takes another 95% of time. And I am speaking with our experience of
developing over 80 Drupal Projects and with over 70 man years of Drupal
experience.

Can't blame a developer for this. Drupal does have a learning curve and
there are constantly new modules introduced and support of many prominent
contributed modules dropped. Its hard to keep up even with the team size we
have.

If a developer spends too much time in architecting, he may not be able to
bill all the hours. And even for a small variation of a requiement, you have
a completely different module available. Or if you don't know that a module
like that exist and you end up custom coding, the next developer will
critize you that you did not use an existing module that already provided
that functionality and client is given links to modules to confirm that.

Solution is to have ratings on modules - i.e which are prominent ones, which
has ongoing support and love from the community and also recommending set of
modules for various type of sites.

Roshan
--
Gloscon Solutions Inc - http://www.gloscon.com/portfolio
* Drupal and Ruby on Rails Powerhouse
Skype : bpocanada
T : 604.630.4292 (Canada)
**************************************************************
This email may contain confidential information, and is intended only for
the named recipient and may be privileged. Distribution or copying of this
email by anyone other than the named recipient is prohibited. If you are not
the named recipient, please notify us immediately and permanently destroy
this email and all copies of it.
***************************************************************

On Tue, Mar 24, 2009 at 6:59 PM, Steve Kessler
<skessler at denverdataman.com>wrote:

> I am working on a couple sites right now where there has been poor
> development by other developers, egregious pricing, lack of communication
> and poor service because the sites were too small for these shops.
>
> What are the best practices for explaining to a user why things that they
> think should be simple tweaks need to be re-done because of how they were
> done in the first place? Do you try and do redesigns or tweak the designs
> they have?
>
> Are smaller shops finding they are getting a lot of business from bigger
> shops that others can't afford any more?
>
> -Steve
>
> Steve Kessler
> Denver DataMan
> 303-587-4428
> Sign up for the Denver DataMan Free eNewsletter
>
> -----Original Message-----
> From: Fred Jones [mailto:fredthejonester at gmail.com]
> Sent: Tuesday, March 24, 2009 7:08 AM
> To: A list for Drupal consultants and Drupal service/hosting providers
> Subject: [consulting] Cleaning Up After Bad Developers
>
> Was hired as a consultant to fix up a Drupal/CiviCRM site with some
> problems. Not surprising that it had problems because it was Drupal
> 5.1 (yep 5.1) and had no user #0 nor #1. That explained why anonymous
> posts didn't appear. LOL.
>
> All of the modules were also never updated beyond the first upload,
> circa Drupal 5.1.
>
> I guess there are those who "dabble" in Drupal, eh? :)
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>



--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/consulting/attachments/20090324/3623a420/attachment.htm>