Bless you Dave, much more patience than I had, I can tell you.

These are all spot on.

Joe

On 03/11/2008, at 9:35 AM, Dave Lane wrote:

Hello Mark,

Mark Harris wrote:
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.

If it's not the decision of the web developer, then I don't expect that
web developer to be around for long.

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?

I disagree here. The developer provides support - the customer chooses the developer based on that ability (assuming the customer isn't totally
naive, which is probably not a safe assumption), and values their
ability to provide that support. The customer should *want* a developer
who focuses on the smallest possible set of technologies (that's not
*too* small to fulfil the requirements).  Otherwise the developer will
be likely to be stretched too far.

The
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.

Agreed. It's the web developer's business decision in that case. Those
who take any work that comes their way regardless of the technologies
specified reek of desperation... (which, ultimately, leads to lack of
respect from the customer)

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?

If my mechanic suggests that I alter the way I drive to reduce the
maintenance requirements and therefore cost of running my vehicle, and I
trust him/her, you better believe I'll listen.  I'd say it'd be a
foolish customer who didn't.

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.

Customers will become expert in whatever technology they're convinced is best for them, and is well supported. But that's not what I was talking
about in the above paragraph.

The "business" I was referring to was the web developer - if the web
developer isn't experienced with his/her tools, then s/he's a cowboy/ girl :)

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.

True, but those naive companies need to expect to pay for the privilege
of being educated.  And, being blank slates, they should be given the
technology that the *web developer* thinks is best, not the one they
happened to see on the self of Harvey Norman or on the infomercial page
of the Tuesday "fun with computers" section of their local mainstream
newspaper.

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
web.

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.

Yes, if it works for the customer, that's their call.  But web
developers shouldn't be "contributing" to it by encouraging it, either
explicitly or tacitly (i.e. by offering to support it).

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.

Actually, I would argue that a CMS, by being more constrained than a
general purpose tool like Contribute (which also requires substantial
configuration to talk to servers, etc.), is conceptually far more
concise.  For a non-technical user, a CMS is generally going to be far
easier to learn, and will offer protection for the customer by allowing
more powerful/dangerous functionality to be hidden until the customer
understands the system sufficiently to know what permission to ask for.
We deal with that sort of situation all the time, and customers
appreciate it.

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.

If you think that Contribute is easier to use than a well configured
Drupal site, then I'm afraid either you haven't used Drupal properly, or
you haven't tried to support an organisation that's decided to go with
Contribute (we're now building Drupal sites for a customer who did
previously and found it unworkable, despite a huge investment).

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.

We've been working doing commercial web development for 10 years... and
we're hiring because we're absolutely at our straps development-wise.
Must be working for at least some of our customers...

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.

Or we should pass them on to a different developer who supports the sort
of solution they need rather than try to serve them ourselves.

I would point out, however, that it's seldom a good idea to adopt a web
solution that solves the customer's *current* requirements and no
more...  because a customer's requirements tend to grow after they've
seen what they can do on the web. It sucks to see businesses (as we do, regularly) who have to throw away a substantial sunk cost in an existing web technology in coming to us, because that previous technology had no
development community, and no upgrade path to a more capable system.

A system like Drupal, due to its modular design and elegant
architecture, is equally well suited to managing a tiny brochure-ware
site as to managing a portfolio of sites with hundreds of thousands of
users for a multinational NGO or corporate. Drupal scales. Contribute
doesn't.  Believe it.

Few customers come to a web developer with the idea that their business
is going to stay the same size forever.  Most are investing in a web
site (and that's what it is: an investment for which they hope to see a
return of some sort) to *help them grow* in some way.  If not, then
chances are they're probably not a good long-term client anyway, and I'd
suggest giving them a miss.

Web developers need to understand these things and help their customers
make informed decisions, not support a disfunctional relationship in
which the less informed party dictates how the professional does his/ her job. That would be like a car driver going to his mechanic and saying - "no, don't use that set of costly but reliable tools you've invested in,
knowing that they would last you for years because of their superior
quality - go to Bunnings and buy the cheap Chinese knock-off versions
for the weekend warrior, which cost bugger all, but will break on the
first use, and result in shoddy workmanship."

Best of luck,

Dave

--
Dave Lane = Egressive Ltd = [EMAIL PROTECTED] = m: +64 21 229 8147
p: +64 3 9633733 = Linux: it just tastes better = nosoftwarepatents
http://egressive.com ==== we only use open standards: http://w3.org
Effusion Group Founding Member =========== http://effusiongroup.com


*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************


================================
Joseph Ortenzi
[EMAIL PROTECTED]
+61 (0)434 047 804
http://www.typingthevoid.com
http://twitter.com/wheelyweb
http://www.linkedin.com/in/jortenzi
Skype:wheelyweb

http://au.movember.com/mospace/1714401



*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************

Reply via email to