Quote:
Originally Posted by zebrastar
So, writing code to restructure a pricing system from top to bottom, requiring code changes to several different aspects (processing fees, new S&H fees, account upgrade fees, etc. etc.) is easier done than writing ONE code for an auto/jersey filter?
I'm not a web developer, and this could very well be the case I Just want to be sure that that's what you're saying.
|
Updating fees could be as easy as updating a set of values (change 20 cents to 25 cents here, etc.) across the site's code. Of course, nothing is THAT simple, but at least the foundation for the fee structure is there, so there won't be as much legwork as developing something from scratch.
I expect that COMC would want to do an auto/jersey filter the most elegant way possible. As a user right now, you can search for "auto" or "autograph" and get a pretty hefty results set, but surely it can't fetch everything, right? In the greater cards database, every auto or GU would have to be flagged as such so that filters are able to select ONLY those cards. If those cards were not flagged that way to begin with, at some point, you would have to double back and do that flagging (or flag their parent sets) to prepare the database for those filters. All of this doesn't even take into consideration user experience design, development time, and quality assurance testing (which I'm sure they'd do A LOT of if they wanted to roll out a new feature like this).
There are exceptions, but in general, developing a feature from scratch requires more resources than an overhaul of an existing item.