So I just reviewed and am overhauling a project another programmer worked on. The programmer worked way harder than he needed to in order to get the project completed. As a result, it didn’t get completed and that’s why I’m taking over.
In this system, it’s a reverse shopping cart. Meaning the customer is selling stuff to the website instead of the website selling stuff to the customer. This particular project is actually a pretty easy one because the programmer doesn’t need to create all of the code, structure, backend, administration, functions and features that would be required for a system like that, instead he/she only has to utilize an API to a system that handles all of that.
The API handles pricing, cart functions, customer functions, order processing, etc. All you have to do is tell it what the customer is doing (adding an item to the cart, removing an item, attempting to log in, etc.), and the system will reply back with success or failure messages and any pertinent details. Our programmer is then responsible for outputting necessary information the the page and moving the customer through the process.
I estimated this project at less than 10 hours. The previous programmer spent 9.5 hours on it thus far and is about half way done. He wrote a ton of code to handle advanced cart management and other object-oriented systems when he didn’t need to. All of those functions, even those concepts were handled by the external system. All he needed to do was send the user actions to the external system and it would handle all of the high-level stuff.
My message here is simple: just because you can build a sophisticated system that can handle everything under the sun doesn’t mean you should. A much smaller, simpler system is going to be faster to implement (and cheaper since time=money), easier to debug (less lines of code in a less complex system) and easier change or manipulate in the future.
Michael Berding April 7th, 2013