[consulting] Staying Current

Sun Mar 29 20:51:13 UTC 2009

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/08f4301d/attachment.htm>