in reply to RE: Design vs. Code vs. Maintenance
in thread Design vs. Code vs. Maintenance

Yeah, I think I should have specified why my worry about webhosting providers. You see, many of our customers already come to us with a webhost that they have used in the past and are happy with. Its my company's policy not to vouch for other company's services, so we tend not to try and push them away from a service that they are already happy with.

In some cases (our larger, corporate) clients own their own servers, but then its likely that I'll have to get it through to the thick-skulled-dinosaur-it-manager that compiling DBD::Oracle requires that you have at least Oracle client installed on his HP-UX (get the drift?).

Bottom line is that unfortunately I am not always able to choose out of a vast quantity of hosting options, and that's why I got stuck with my MakeHTML($template,%HASH) solution. :o/

Thank you for the great advice on HTML::Template, I've skimmed through and seems to be exactly what I was in need for! (and my most common webhost, HWay, has it in their module list)
  • Comment on RE: RE: Design vs. Code vs. Maintenance

Replies are listed 'Best First'.
RE: RE: RE: Design vs. Code vs. Maintenance
by lhoward (Vicar) on May 17, 2000 at 20:49 UTC
    I understand getting stuck with a less-optimal solution because of choices made elsewhere. About all you can do it inform the client of the ramifications of their decision and prepare.

    In the first case I would handle it like this. Tell the client company:

    Since your current webhost doesn't support A, B, or C we can develop your project in X weeks and it will take about Y effort to support in the future. It will scale like Z. If you find a webhost that supports A, B, and C then we can implement it in T weeks and it will take about U effort to support in the future and it will scale like V.
    Break it down in such a way that both their operations staff and accounting departments can both understand the ramifications of the choice they've made. If they choose to stay, at least they know what tradeoff they made (and hopefully they'll come back to you when they realize the error of their ways). Also, if you can get your company to change policies and start recomending a (or some) particular webhost(s), you may be able to cut a deal w/ the webhost that would let the clients get a lower rate (since you'd be bringing them in in bulk).

    In the second case (and I've been in that EXACT same spot before w/ HP-UX and Oracle even). be sure you include in your specifications details requirements of what they must have installed (preferably in an early spec that upper-managemet signed-off on). Make sure this is widely distributed to all parties related to your project in the client company. Make sure you are ready so if it comes down to the dinosaur manager problem you can place blame squarely on his/her shoulders and show him/her that upper management has already signed-off on it. It still isn't a fun fight to have, but being prepared can make it an easier win.

      Hehe, I failed to mention that the 2nd case was while I was doing work for Oracle Brazil... :o) We are currently maintaining their site.

      On the 1st case though, that sounds like perfectly sound advise, and we've tried doing it the past. As I said, its much more of a company policy problem when their host goes down, or emails cease to work, or something else totally none web related and they come back at you for support since "it was your recomendation".

      As they say, "Now that's whay I call a sticky situation!"