Hey there,<br><br>I&#39;d like to echo Brian&#39;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&#39;ll do things the drupal way b/c of its long terms benefits. But say you have a client who&#39;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?<br>

<br>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&#39;s their perogative since they&#39;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&#39;m there to meet their needs. If I&#39;m unwilling or unable to do that, I&#39;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&#39;s the client who needs to decide if it&#39;s worthwhile to rebuild crap code or not since it&#39;s going to be their problem in a month, a year, whatever.<br>
<br>gwen<br><br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 6:41 AM, Brian Vuyk <span dir="ltr">&lt;<a href="mailto:brian@brianvuyk.com" target="_blank">brian@brianvuyk.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Steve,<br>
<br>
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&#39;t enough benefit in rebuilding it.<br>


<br>
On the other hand, if your client had a &#39;friends&#39;-type module written in an external PHP script dumped into the site&#39;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 &#39;module&#39;, gave them far more features, and there is a much wider base of developers familiar with Buddylist than some guy&#39;s poorly written custom implementation.<br>


<br>
As to the second part of your post, I haven&#39;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.<br>

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