By moshebeeri on

The modularity of Drupal is wonderful but I think that the modules interfacing with the whole system should be refined,
the problem is that old version modules do not fit into newer Drupal version, I can see it getting spaghetti in the future as I fined it now.
I think you should consider a mechanism or an architecture that will support old modularities of the system.

BTW,
I am a C++ J2EE Developer with 12 years of experience (new to Drupalist).
just working around with Drupal for couple of weeks, trying to build community web sites and I think Drupal
is the smartest web development system I know.

⋅ Categories: Drupal 6.x, Drupal 7.x

Comments

markus_petrux’s picture

markus_petrux commented

You may want to read this:

http://drupal.org/node/65922

I come from the mainframe industry, I was there for a few years, and I have never worked like I do with Drupal. So I think I know what you mean, but after some time of playing around the web development business you can see why Dries wrote that, and why Drupal is like it is.

Doubt is the beginning, not the end of wisdom.

moshebeeri’s picture

moshebeeri commented

I understands it is difficult to find an architecture that will remain over versions, but the way Drupal is managed I think it is possible.
there hundreds of modules that where contributed and there are hundreds that have been developed by core teams in Drupal.
Upgrading those modules to new version of Drupal require thousands of working hours, it means millions of Dollars in cost.
It would not be accepted in any software company, nor in the academy.
The Drupal architecture mast support clean migration of modules.

criznach’s picture

criznach commented

Having been a Drupal developer for nearly 3 years, I've now been through two rounds of major version upgrades with many clients. Before Drupal, I did many types of development, including C/C++, VB, and some Java. When I started with Drupal, I was surprised by the chaotic, yet agile development environment.

I now find it rather refreshing that we don't drag antiquated architectures of old versions along as baggage. By the time a client does a major version upgrade, their vision and the technology have evolved enough that a global redesign is usually a good idea. Because of the core, and major module data upgrade paths, most of a site's data upgrades easily. It's the bells and whistles that don't upgrade well - the faster-moving technology.

Modern Drupal sites can push the limits of cheap hosting. If we were to include backward compatibility in every release, I believe cheap hosting would be out of the question. Drupal would require too many resources to run.

For me the bottom line is:
A Drupal site can be in the "supported" realm for 2-3 years. In that time, web technology WILL have advanced significantly. Client expectations will advance accordingly. Try to keep your basic functionality in modules that you are confident will be around for the long term (cck/views). If we're still working with that client in 2-3 years, they should be able to justify the expense of retrofitting the latest bells and whistles. If they don't, their site will LOOK 2-3 years out of date.

http://www.trailheadinteractive.com