[consulting] Staying Current

Sun Mar 29 20:31:10 UTC 2009

> We recently upgraded a site we did years ago, from 4.7 to 6, and by far
the biggest complications were in dealing with contributed modules, not the
custom modules we had done ourselves.

OK. Now what if it was another shop that had to update your code? Of course
it's easier to update your own code, but what if a meteor was to strike
PingV headquarters? Would it be easier for me to look at what you had done
using CCK + Views than it would be for me to decipher your FormAPI + custom
queries? Obviously, it would.

> Coder module and familiarity with the Drupal API changes can make
upgrading a custom module much easier than dealing with contributed modules
that don't have smooth upgrade paths or have disappeared altogether

I'm curious: where do you draw the line with what you use or don't use from
contrib? Are you saying you don't use Token, Pathauto, CCK, Views, OG, or
Image/Imagefield? It seems like your argument is just a short step removed
from the "I'll build my own CMS". Sure, dealing with contrib can be a royal
pain in the butt, but try deciphering a single developer's solution ot the
problems that any of those module try to address and I think you'll see my
point: you can't use contrib all the time, but you should use it *whenever
possible*, and try to fix problems you see with it, rather than going off on
your own.

> There are some false assumptions I see out there: That you are better in
every case if you use contrib or give back to contrib.

I don't really think that's what's being said here, and it's certainly not
what I'm saying. Every site we build includes a large portion of code that
is completely custom for that site. The key is to understand that there's a
cost in maintaining that code moving forward, much of which will come from
further integrations or updates/upgrades, and that cost is almost certainly
higher than the cost of maintaining contrib (since obviously the cost can be
spread around "the network", instead of falling all on one "node").

>If all I need is a screwdriver, I don't need to use a Leatherman tool. The
screwdriver is going to do the job better anyway. And when I need to
upgrade, all I'm upgrading is the screwdriver, not hoping that the
Leatherman still supports the kind of tip I need.

But you're not talking about *using* a screwdriver instead of a leatherman,
you're talking about *building* a screwdriver when a leatherman's available.
Yeah, the leatherman probaby does more than you need right now, but you
can't really anticipate whether any of those other included tools will be
necessary in the future, and you can be sure that your screwdriver will have
one potential avenue of support (you) while the leatherman will be widely
used and supported. And again, this seems like an argument against Drupal
itself, not just contrib. Don't use the poll module? How about the core feed
capabilities? The PHP Filter? No? Then why use Drupal?

>Awkward analogy, perhaps, but there really are times when the open source
approach costs more now and costs more later.

That's possibly true, though I sincerly doubt it. OSS isn't a panacea, but
on long term costs I'm guessing that it will beat proprietary software on
price 95% of the time.

> For example, if we write a simple module to generate a page that could
have been generated by Views plus a handful of other modules, it doesn't
always follow that the simple custom module will result in a rougher upgrade
path. Who says that combination of modules will be available?

Well, while you can't be sure of anything in OSS (in life?), you can be sure
that all the other people/companies that are using Views plus that handfull
of modules will have to come up with an upgrade path in the future. It might
not be within your desired time frame, but it's waaaaaay more reliable (and
almost certainly cheaper) then hoping some developer or shop will be
available and willing to port all your custom code when the next version of
Drupal comes out.

> It's not about "what you're selling." It's about what the client needs,
isn't it?

I don't assume our clients know what they need on the technical side. That's
why they hire experts, right? It's up to developers to guide their clients
business goals into sustainable technologies and best practices.

> +1 on the patching! But I don't agree that using as little custom code
(which I will take to mean custom modules) is always best serving the
client. There are many instances where a simple custom module can replace
three or four complicated modules cobbled together and containing a bunch of
code for functionality not needed. There are instances where we might write
a custom module rather than use a contrib module simply for site performance
and responsiveness.

This is no doubt true, and we certainly work this way. The way I would put
it is "use contrib *when possible*, even if it seems like a bit of overkill
at times."

> And that doesn't mean upgrading will be harder, either.

True enough, but it certainly makes it more likely that someone else will
have a harder time keeping the code/site up to date. But, again, where do
you draw the line? Do you hack core if that's the easiest way to go?

> To me the real problem is still incompetence.

Can't argue with you there, though I would add inexperience and lack of
commitment to the "OSS/Drupal way" as equally problematic.

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

2009/3/29 Laura Scott <pinglaura at gmail.com>
>
>> The key to this is your assumption that there is "lots of customization".
My goal is always to do as *little* customization as possible by finding
modules that are a good fit and have lots of flexibility, or by educating
the client on ways to bend their goals a bit to do things in a way that they
can be done without a lot of customization, or by writing patches to modules
that make them flexible enough to do what I need them to do and contributing
the patches back so that they will be maintained and supported, and by
trying to avoid using modules that are not widely-adopted (which therefore
may have upgrade and maintenance problems).
>
> What is "customization"? I'd say it goes beyond custom code and into
configuration as well. And configuration is something you can't really put
under version control. We provide alternatives so clients can make informed
decisions, but we don't think
>
> We recently upgraded a site we did years ago, from 4.7 to 6, and by far
the biggest complications were in dealing with contributed modules, not the
custom modules we had done ourselves. Coder module and familiarity with the
Drupal API changes can make upgrading a custom module much easier than
dealing with contributed modules that don't have smooth upgrade paths or
have disappeared altogether. (Remember Flexinode!)
>
> There are some false assumptions I see out there: That you are better in
every case if you use contrib or give back to contrib. It's a nice ideal,
but it doesn't always serve the client. If all I need is a screwdriver, I
don't need to use a Leatherman tool. The screwdriver is going to do the job
better anyway. And when I need to upgrade, all I'm upgrading is the
screwdriver, not hoping that the Leatherman still supports the kind of tip I
need. Awkward analogy, perhaps, but there really are times when the open
source approach costs more now and costs more later.
>
> For example, if we write a simple module to generate a page that could
have been generated by Views plus a handful of other modules, it doesn't
always follow that the simple custom module will result in a rougher upgrade
path. Who says that combination of modules will be available? One clear
argument in this case for the Views approach would be that the client needs
to be able to change that configuration through an admin interface. But
another clear argument the other way might be to optimize performance on
that page, or to put the progressive enhancement of that functionality under
version control for developers. It's never cut and dried, is it?
>
>>  I'm talking about big sites with lots of customization, where clients
might spend well over 100k on customization.  I'm just questioning whether
those who build those sites are building in -- or being upfront -- about the
cost of upgrading to D6 and then D7.
>
> What the developers are telling the client is important no matter what the
size. Just because a site is large and complex with lots of customization
doesn't mean the client was misled. There are many different approaches to
web properties. We are quite up-front about the costs of upgrading (which
are far far lower than developing from scratch, as long as the site, custom
or not, was developed following best practices). Compared with the costs of
large integrated systems like Vignette, it's a bargain.
>
> It's not about "what you're selling." It's about what the client needs,
isn't it?
>
> And it's open source, which means there is no real EOL. You can always
change/fix/update the code yourself, which is something you cannot do with
proprietary systems.
>
>> 1) We try to use as little "custom code" as possible. If we are changing
the way a module works, we submit our changes as a patch and work to get the
patch committed. This means easier updates in the near term, and (hopefully)
an easier upgrade path in the medium-long term.
>
> +1 on the patching! But I don't agree that using as little custom code
(which I will take to mean custom modules) is always best serving the
client. There are many instances where a simple custom module can replace
three or four complicated modules cobbled together and containing a bunch of
code for functionality not needed. There are instances where we might write
a custom module rather than use a contrib module simply for site performance
and responsiveness.
>
> And that doesn't mean upgrading will be harder, either.
>
>> It strikes me that we've moved away from "Should Drupal be supported for
more than two releases?" to "Are there salespeople that mislead clients
about the full cost of acquiring some piece of technology?". And since the
answer to the second question is so obvious, what are we even talking about?
>
> To me the real problem is still incompetence. We don't run into many
clients who have sticker shock over upgrading costs. However, every week we
are approached by clients who hired the wrong company to develop their site,
and spent all their money on a site that is not simply "incomplete" (which
can happen if a project runs out of funding) but was actually built with
such incompetence that the only solution is to start over. There's no happy
answer in these cases.
>
> And that's part and parcel with the world of open source. The upside (if
you could call it that) is that lack of competence ranges deep, far and wide
in the proprietary world, too. Caveat emptor is always the message.
>
> Laura
>
>
> _______________________________________________
> 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/20090329/f3851c82/attachment-0001.htm>