Shopping carts are incredibly complex. I believe I just said that in the last post, but it is repeated here as an entrance into this topic.
It is their very complexity which makes them often lag behind in function and features.
No two stores are the same. I think I said that too. That means that carts have to be very flexible in how they do things, allowing a LOT of configuration options. Typically when setting up a high function cart, you’ll spend hours just working through the configuration options – do you want this feature, if so, how do you want it to work… ok, then how about the next one… ? It is a tedious process, but nothing compared to the original tedium which the programmers endured to give it all those choices!
Because carts are so complex, they typically come in three categories:
1. Young, immature, and barely functional. An incredible number of carts fall into this category, and can have all sorts of limitations that you would not believe.
2. Old, clunky, with a lot of choices, but not necessarily ease in USING those functions. Anything that forked from OS Commerce, and the giant itself, falls into this category, as do a number of other carts.
3. Extortionately priced. Ok… so a successful business that makes millions a year can afford a licensing fee of $4000 per year, or $1500 for every version of a cart. Small businesses and startups cannot! The sad thing is, even if they are in this price range, the VAST MAJORITY still fall into the “immature” or “old and clunky” categories!
The reason those old and clunky ones hang around is because they already have a HUGE code base, large user base, and established developer base. It takes a long time to produce that much code to do that many things (the average cart contains between 2000 and 20,000 code files), and to get that many people both using it, and assisting with the development of new features. They tend to build onto it, so that it often looks like what started out as a 2 bedroom single wide and ended up as an apartment complex – funny looking, awkward to get from point A to point B, and seriously in need of a rebuild!
But rebuilding is hard. If you knock out one section, it may affect another, and what seemed like a simple little modification may domino on you until you are rewriting half the files just to modify one feature. And if you are going to modify those files, why don’t you do it right, and not have to redo the changes you just did when you go for the next round of improvements! Like the mechanic that says, “while we are in here replacing the clutch, we really should do the water pump at the same time since we have to pull the engine anyway”.
So many of those old carts, build on a code base that was created long before anyone had any expectations of user friendliness or standardized features, are still clunky. They get better slowly. Their very complexity seems to keep half their functions in a state of obsolesence at any given time. As each of the worst functions is improved, other functions slide into the mire of antiquity. It is a battle they will likely never win.
What does this mean to you? It means there is no perfect solution. You are going to have to compromise. Choosing smart though, makes sure that you compromise where it matters least. That you go forward with something which allows you to at least sustain it in the most efficient manner.
We feel that the cart we chose to teach about in our Database Shopping Cart Intensive Course (Beginning Saturday the 23rd, 2008 through the University of Wyoming Enrichment Program) fits that criteria. It isn’t perfect, but it is usable, flexible, functional, and more sustainable than any others that we’ve found.