[consulting] Cleaning Up After Bad Developers

[Gwennie Cakes]

Hey there,

I'd like to echo Brian's point about giving the client the information to
make an informed decision about rebuilding crappy code vs. hacking it up
further. Given my druthers, I'll do things the drupal way b/c of its long
terms benefits. But say you have a client who's doing some site with a
limited shelf life (e.g. a site associated with some marketing campaign) or
some site that requires changes in a very short, hard timeframe (e.g. a site
that will be mentioned on some date on some tv program). Is the client
really going to want to put the time, resources and money into doing things
right vs. doing things fast?

I feel my job is to let the client know their options--what each option
would require, their pros/cons, what option I would recommend--and then
follow up based on what they decide. If they go against my recommendation
(which has happened in the past), that's their perogative since they're the
ones who own, are ultimately responsible for and benefit from the site. I
might argue in favor of my recommendation more or less strongly depending on
the case, but in the end, I'm there to meet their needs. If I'm unwilling or
unable to do that, I'll walk away and let someone else do it. But if I do
need to hack up a site, I try to help future developers by doing things like
setting up an svn vendor branch and/or commenting hacks like crazy and/or
writing some quick docs. But in the end, it's the client who needs to decide
if it's worthwhile to rebuild crap code or not since it's going to be their
problem in a month, a year, whatever.

gwen


On Tue, Mar 24, 2009 at 6:41 AM, Brian Vuyk <brian at brianvuyk.com> wrote:

> Steve,
>
> I usually try to present the client with a long-term cost-benefit analysis
> explaining why rebuilding a feature done incorrectly by a previous dev will
> save them money in the long run. To be honest, if there is a
> incorrectly-implemented feature that the client does not ever plan on
> changing, expanding, or updating, well, usually there just isn't enough
> benefit in rebuilding it.
>
> On the other hand, if your client had a 'friends'-type module written in an
> external PHP script dumped into the site's root... well, there was a good
> case to reimplement using the Buddylist module at the time. It cost my
> client 10% of what they paid to develop the initial 'module', gave them far
> more features, and there is a much wider base of developers familiar with
> Buddylist than some guy's poorly written custom implementation.
>
> As to the second part of your post, I haven't really noticed that. I have
> seen an upswing in contracts going around, despite the recession we are in.
> I wonder if it is due to maintenance contracts being resources, or companies
> trying to get some website updates in while the money is still available in
> order to have the upper hand on their competitors going into the recession.
>
> Brian
>
>
> Steve Kessler 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
>>
>>
>
> _______________________________________________
> 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/2c932948/attachment-0001.htm>