[consulting] Staying Current

[Alex Urevick-Ackelsberg]

> The whole flavor of this post posits an attempt to regiment software
development strategy.

Drupal *already has a regimented development strategy*, which is what some
are arguing against here (IMO). I feel like this is a necessary framework to
make order out of the chaos, and is what is enabling Drupal to grow at such
an astonishing rate.

> Are you saying people shouldn't use the Form API to make a custom form?

Nope. I am saying that there are medium-long term costs of doing things this
way. Assuming you are asking about using the FormAPI directly as opposed to
CCK, then there's the cost of updating the form. But, my usual worry isn't
with people writing their own modules that interact with Drupal's APIs, it's
that they bypass the APIs altogether when they either don't understand them
or get frustrated with them. That is waaaaay more expensive than either of
the other cases, both of which could be fairly easily deciphered by a good
Drupal developer.

--
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 Sun, Mar 29, 2009 at 4:51 PM, Victor Kane <victorkane at gmail.com> wrote:
>
> The whole flavor of this post posits an attempt to regiment software
development strategy.
>
> Are you saying people shouldn't use the Form API to make a custom form?
>
> Above and beyond the answer to that question, yes, another developer will
have to upgrade a prior developer's Form API invocations, and that is not
wrong, that is part of any normal Drupal website application developement.
>
> That needs to be considered.
>
> Victor Kane
> http://awebfactory.com.ar
> http://projectflowandtracker.com
>
>
> 2009/3/29 Alex Urevick-Ackelsberg <kaos777 at gmail.com>
>>
>> > 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
>>
>>
>> _______________________________________________
>> 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/42485a42/attachment-0001.htm>