[consulting] preparing clients for Drupal 5 obsolesence

Tue Mar 10 18:04:45 UTC 2009

> So it's not about driving clients away or not: it's about satisfying
concrete requirements with good engineering.

Point taken, and I agree to a large degree, though with a caveat. I, for
one, almost never go into a project thinking that the clients knows what
their requirements are (at least on the technical side), which is why
they've decided to hire Drupal experts- to help translate their business
goals into a technical reality. I usually flinch when I talk to a potential
client that "knows" what their technical requirements are prior to working
with devs who understand the subtleties involved in the tech decision making
process (this is not always the case- we have some incredible clients that
do in fact know exactly what they want/need on the technical side).

--
Alex Urevick-Ackelsberg
ZivTech, LLC
http://zivtech.com
alex at zivtech.com
office: (267) 940-7737
cell: (215) 866-8956
skype: zivtech
aim: zivtech

On Tue, Mar 10, 2009 at 1:29 PM, Victor Kane <victorkane at gmail.com> wrote:

> On Tue, Mar 10, 2009 at 10:22 AM, Alex Urevick-Ackelsberg <
> Alex at zivtech.com> wrote:
>
>
>
>>  > A website developed in Drupal 5 last year is not at EOL.
>>
>> It will be in 5 months. This is a fundamental decision that has been made
>> by the Drupal community, and I think it's a damn good one. If they need a
>> longer life cycle, they probably need Acquia (or a consultant such as
>> yourself or Eric that is willing to maintain a non-supported version of
>> software).
>
>
> It's the requirements! The client has the basic constitutional right to set
> requirements and have them complied with. Which is another way of saying,
> it's people's needs we should bear in mind. If a website application meets
> requirements, you should not disturb it, it might be all they need.
>
> This is not to say that we should block progress. The more progress and the
> quicker it is, the lower the costs and the lower the migration costs also.
>
> But development is a requirements driven process, or should be.
>
> Also, I understand that "people's needs" are also people's needs in 5
> months, not just now; and as good consultants we should point our clients in
> a direction towards constant optimization.
>
> But requirements driven, and the needs of Drupal and the community have
> their own time frame and characteristics.
>
> So it's not about driving clients away or not: it's about satisfying
> concrete requirements with good engineering.
>
>
> Victor Kane
> http://awebfactory.com.ar
> http://projectflowandtracker.com
>
>
>
>>
>>
>> --
>> Alex Urevick-Ackelsberg
>> ZivTech, LLC
>> http://zivtech.com
>> alex at zivtech.com
>> office: (267) 940-7737
>> cell: (215) 866-8956
>> skype: zivtech
>> aim: zivtech
>>
>>
>>
>> On Tue, Mar 10, 2009 at 12:57 PM, Victor Kane <victorkane at gmail.com>wrote:
>>
>>> This is a fascinating discussion.
>>>
>>> I agree about the website being living and breathing, but if I just
>>> bought a new car, and there are some inventions in the course of the next 18
>>> months, I don't want to be told that if I don't trade in immediagtely, I
>>> deserve what I get.
>>>
>>> All I am saying is that there are two living, breathing cycles, that of
>>> the car and that of the automobile industry on a technological basis.
>>>
>>> Some people do trade in their cars every 18 months, but they shouldn't be
>>> told they have to.
>>>
>>> A website developed in Drupal 5 last year is not at EOL.
>>>
>>> Starting a new project in Drupal 5 would be wrong, however.
>>>
>>> I think this EOL criteria you bring up could be very useful. Just I think
>>> there is one for Drupal and another for the site.
>>>
>>> Victor Kane
>>> http://awebfactory.com.ar
>>> http://projectflowandtracker.com
>>>
>>> On Tue, Mar 10, 2009 at 8:27 AM, Susan Stewart <
>>> hedgemage at binaryredneck.net> wrote:
>>>
>>>> Victor Kane wrote:
>>>> <snip>
>>>> > They want a website application that will last several years and have
>>>> > every right to receive that. Only if they ask for new functionality
>>>> and
>>>> > the cost of implementing it is cheaper if an upgrade is involved
>>>> should
>>>> > the client be expected to change to the new shiny Drupal just because
>>>> we
>>>> > are excited about it. I am against the "no support after 9 months"
>>>> thing
>>>> > and in favor of backport support.
>>>>
>>>> I *absolutely* disagree here.  If a client does not believe that a web
>>>> site is a living, breathing thing requiring regular care and
>>>> maintenance, the developer has failed to educate him/her.
>>>>
>>>> I often use an automobile analogy when explaining this to client: sure,
>>>> you can buy a new car and never change the oil, just as you can get a
>>>> new web site and never do a security or bugfix update.  However, it
>>>> won't run smoothly for long.  Similarly, regardless of how well you keep
>>>> up with oil changes, the breaks and tires must eventually be replaced --
>>>> yes, it can be expensive, but not as expensive as getting in a car
>>>> accident -- it's part of car ownership.
>>>>
>>>> When I first spec out a new project, I start talking to the client about
>>>> maintainability.  We've talked already about how using Drupal lets them
>>>> take advantage of development done by the whole community, so it goes
>>>> hand it hand to point out that in order to take advantage of this, all
>>>> we need to do is stay on a currently supported version of Drupal.
>>>>
>>>> For clients who can't afford an expensive upgrade process, we carefully
>>>> choose our modules from the beginning, limiting ourselves to those most
>>>> certain to have a simple upgrade path.  My company's clients all know
>>>> from the start which modules will make upgrading more expensive, and
>>>> make those choices with long-term TCO in mind.
>>>>
>>>> Just glancing at my recently completed projects list, I'd guess that
>>>> about 1/4 of my clients could do a d6-d7 migration for under $300.
>>>>
>>>> > The solution is as web consultants, to be prepared to work on
>>>> different
>>>> > versions.
>>>>
>>>> Different versions, sure, but pinning my company's reputation on
>>>> something past it's EOL isn't good for business.
>>>>
>>>> > So:
>>>> >
>>>> > +1 on starting all new projects with Drupal 6
>>>>
>>>> We've been doing that for ages, +1
>>>>
>>>> > +1 on maintianing a centralized, community supported backport
>>>> > maintenance repository
>>>>
>>>> A waste of time and energy, and I don't want to see it on Drupal.org --
>>>> I feel that would be tantamount to the Drupal community at large
>>>> endorsing the use of EOLed versions, and could only damage our
>>>> reputation for quality products.
>>>>
>>>> Big, big -1
>>>>
>>>> > -1 on ultimatums to the clients which will give Drupal a bad name
>>>> (i.e.
>>>> > "if you use Drupal you have to do frequent and expensive upgrades").
>>>>
>>>> It's not an ultimatum, and major version upgrades are neither that
>>>> frequent nor that expensive, *if* the site was planned well from the
>>>> beginning.
>>>>
>>>> I won't tell a client it's okay to stick with an EOL'ed product -- my
>>>> clients trust my advice, and know I won't compromise its quality just to
>>>> avoid telling them something they may not want to hear.
>>>>
>>>> Most of my clients just don't see major version upgrades as all that
>>>> painful, and I believe that is because they have been prepared for this
>>>> from day one.  The ones that tend to have sticker shock at upgrade time
>>>> are clients who began their project with another developer who just
>>>> slapped together whatever modules worked to get a desired result,
>>>> without thinking about how easy those modules would be to upgrade.
>>>>
>>>> > If you feel that you don't want to be bothered with Drupal 5 anymore,
>>>>
>>>> It's not that anyone don't want to be bothered, it's that there are a
>>>> limited number of versions we, as a community (let alone one company)
>>>> can support at once while providing the highest possible quality of code
>>>> and service.  More versions spreads us thinner, thus reducing quality.
>>>>
>>>> > offer your clients a very cheap or free upgrade to 6. But let's not
>>>> give
>>>> > the impression that Drupal is an unstable platform, it isn't.
>>>> <snip sig>
>>>>
>>>> The idea that an upgrade needs to happen occasionally, and that that
>>>> upgrade comes at some cost, does not give any intelligent person the
>>>> impression that Drupal is unstable.
>>>>
>>>> For sites that were developed with an eye toward future maintainability,
>>>> upgrading to the next major version of Drupal is a fairly painless
>>>> process.  I have *always* refused to work on EOL'ed versions, except to
>>>> upgrade them to a current version before doing anything else.  Sometimes
>>>> this loses me a client, but often those clients come back to me later,
>>>> having received poor service from whatever developer they did talk into
>>>> keeping their site woefully out of date.
>>>>
>>>> --Susan
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20090310/7d2a7a4e/attachment.htm 