[development] RFC: drupal as a moving target

[fintan at io1.biz]

I am someone who nearly had a heart attack when I first found out about this
tendency to just drop / change stuff in core api.   My background is
enterprise development so this really did not sit well with me at all and
nearly made me back out of our decision to bet the bank on Drupal.  But we
stuck with it and now, while I fully understand your view Ivan I must
disagree.

To be clear, my view is a commercial one as the owner of a company who makes
money from Drupal via consulting and running our own Drupal sites, not one
of a developer or drupal purist!

Overtime the vast majority of software "bloats" by its very nature and if
you don't allocate time to revisit software on a semi regular basis it
becomes a mass of spagetti as a result of "tactical" fix's and changes,
which complicates development and slows it down.

The real commercial question for me is whether is more efficient to
regularly have to go back and revisit code in order to update it or whethers
its better to live with a reduced workrate that exacerbates over time for
all developers (our own and the community).

The answer is simple, commercially its better that developers have to
revisit old code on a semi regular basis.

As they inevitably improve the way it was written as they have gotten better
as developers over time and in a lot of cases their knowledge of drupal has
significantly improved.  

The other massive benefit is that when they revisit it they will see
oppurtunities to tie in with new modules.  At one point CCK and Views were
new modules, a lot of people did a lot of work to make sure when they
updated for d5 that their modules played nicely with these and we all
benefitted.

The end result is that as long as you build your processes around the fact
that it can and will change you end up with a more efficient internal
development environment.  As long as you take a longer term view, there is a
net commercial gain as a result of improved software, more rapid adoption of
new more advanced methods/modules and more rapid delivery to clients.


My 2c.

Fin

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of Jakob Petsovits
Sent: 29 April 2008 11:24
To: development at drupal.org
Subject: Re: [development] RFC: drupal as a moving target

On Tuesday, 29. April 2008, Ivan Sergio Borgonovo wrote:
> Is it mature and complex enough that API don't have to be changed
> twice in a row for the same functionality, so that changes for
> each releases will impact just few aspect so that can be easier
> managed during an upgrade cycle?

Ivan, I feel your pain, I'm having a hard time with porting my modules in
time 
as well (in addition to "new features" work). The problem does exist.

However, what I miss from your mails is a constructive proposal how to make
it 
better. Even now, the APIs are not changed for the fun of it but always come

with a significant improvement. You request that the core devs take care not

to change stuff *without a good reason*, but that's what they do already.

So the question is if you want to have the APIs freezed even if there would
be 
a good reason to change them, and *that* is what the policy applies to.
Do you want to have some of those APIs freezed as well? Possible answers:

"No, because they do indeed make Drupal better, even if it causes more
effort 
on upgrading."
In that case, we're at the status quo, and the discussion is over.

"Yes, because the cost of upgrading is more important than the cleanest 
possible Drupal core."
In that case, you disagree with the community (including me), and we expect 
you to make concrete proposals which type of API changes should be frozen 
under which exact circumstances, and present compelling arguments why that
is 
better than the status quo.

You argued that Drupal is becoming stable and mature enough to freeze some 
aspects of the API. If that is the case, I believe that no more API changes 
will be written up for these areas, and the problem will be solving itself
in 
time. However, I believe that Drupal has still years to go until it reaches 
that state of maturity, and that each API change causes more good than harm 
in the end.

If you believe that some of the changes from Drupal 5 to 6 caused more harm 
(in terms of slowing the upgrade process) than good (in terms of
consistency, 
long-time maintainability and important features), then by all means,
"show us the code".

Which changes would better have been left out in your opinion?
I'm keen on seeing examples from you, because the process can only be
changed 
if we recognize what actually went wrong. If you can't find good examples, 
then this whole discussion is moot because there's nothing to complain
about.

Regards,
  Jakob