Dave Lane wrote:
I'm sorry, Mark, but that is not a winning strategy in business.

Dave, the business decision is not that of the web designer. While web design may be his business, it's not the business of his client.

As a web developer, you *must* design for maintainability.  Anything
else is a disservice to both your business and your customer.

Not arguing, but it must also work for the client, otherwise you are merely building ongoing work for yourself, in doing the maintenance. Offer options, by all means, but the result *must* be within the client's capability set or it won't get used. How much value have you then added to the client's business by imposing your own ideas on their naivety?

customer is not always right.  The customer hires you because they
perceive you to have expertise they don't, and they trust your skill and
judgement on their behalf.  If they don't have that respect for your
ability, they're not the right customer for you.

Fine. Say so and get out, but if you take the job, you take the constraints and responsibilities that come with it.

I'm not saying that
you should tell them their wrong, but you should explain the
shortcomings of the methods they request and explain the advantages of
the tools you've chosen...  if you can't do that then you probably
haven't thought very carefully about choosing tools.

That's not what Joe was advising. What he said was:
        "you should never let the client specify the technology,
        that's YOUR job The technology you decide to deploy should
        be a result of having defined the strategy and scope of a
        project and identified the resources for ongoing content
        and support."

which is a pretty tall ask for a web designer, not to mention arrogant. Do you get your mechanic to tell you how to drive your car? He's far more experienced with vehicles than you, so he should know, right?

Ultimately, a business must select its technologies (the smallest set
possible to do the job well), become expert in them, and then maintain
those skills for the length of their relationship with their customers.

See, it's the whole "become expert with them" that's the problem. They don't have the desire to become expert in something that is a commodity to them. Many companies don't have web specialists on staff. If they're lucky, they have a librarian, who does records management, maybe a little DTP and gets stuff onto the web. They don't *want* a web designer on board, or they'd be hiring one instead of farming the work out to you.

If that's how they see it, that's their business. Myself, I'd try to get them to see that it's a major strategic part of their future business *but* if they won't go there, I'm going to build them something they feel comfortable with, with an outline of what it could become, if appropriate. I'm not going to push a company into "Web 2.0" if they still believe a little man sits in the printer pushing out paper.

I completely agree with Joe's statement - using an app like Contribute
is a step backwards in most cases, both for the customer and for the

If it works for them, it's their call. A simple site set up by someone who knows what they're doing can be managed just fine with Contribute. It's not likely to win any awards (and it probably won't do a lot for their bottom line) but we don't always get to paint the Mona Lisa. Sometimes, we just put the colour on the canvas and move it about a little.

CMSs, if chosen wisely (and the open source ones are better than
anything proprietary, so it'd be foolish not to go down the open source
path), implemented by *knowledgeable* developers with an appreciation
for web and software best practice (e.g. standards compliance, source
code control, change control procedures, etc.) and the will to adhere to
it, with ongoing maintenance in mind.

Your point assumes knowledgeable people doing the maintenance. My point says, if they're asking for Contribute, they're short on knowledgeable people. I agree completely about the OSS thing (obviously) but you need to remember that, for Joe Sixpack, OSS may still be the big scary thing. You've got to be ready for OSS and understand what you're doing before you'll bring it into your business. I know that doesn't make rational sense, but people do behave irrationally, especially about technology. Contribute comes with a brand that they know and they feel comfortable with that.

Those who don't feel responsible for learning about and adhering to best
practice should look for another line of work.

Well, it's their business, isn't it? And, as a supplier, it's yours to supply what they need within the constraints they specify. It's also your job to give them something they will use. Drupal may be simple for thee and me to manage, but the boss's PA will be very wary when faced with the options contained within.

The road is littered with the remains of web development companies who
tried to support whatever solution de jeur their customer specified.  If
you customer requires you to use their choice of technologies rather
than yours, my advice is to get a new customer.  That sort of customer
will make your life miserable and cost you money in the long run.

For crying out loud, IT'S NOT ABOUT WEB DEVELOPMENT!!! It's about business - web development may be your company's lifeblood but it's just a tool to them. And if they're not ready to run a nailgun with a sequential trip trigger, then just give them the damn hammer, please.

Now, if you can educate them about the benefits of the nailgun, give them the proper training and confidence to use it, show them the safety procedures associated, ensure they have the necessary resources to manage it, then by all means offer to sell them a nailgun. If they only want a hammer, that's what you should sell them instead.



List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm

Reply via email to