Requiring labeling and/or outright banning genetically modified (think about what that means...) food products for which we had no good human safety data or studies seems prudent, not "knee-jerk".

...without the will and courage to do something about it. It's not the idea guy who is creating the real value - it's the guy who took the idea and had the courage to try and do something with it. Probably everyone on /. has had an original idea at some point - how many of us have taken the step off the curb to actually quit our job (or sacrifice personal time) and try and bring it to fruition? Moreover, how many of us have had the belief in ourselves and our idea to seek out the best and brightest in their field (or anyone at all for that matter) and ask them to follow our lead?

...where it belongs, alongside other phobias, irrational behavior, groupthink, etc.

Keeping commented out code around is not only distracting to developers but harmful. Code in comments isn't syntax checked, isn't compiled, and isn't tested and therefor quickly begins to suffer from bit rot. It would be better to refactor the surrounding code to work with different plugin-able implementations and to fully support both the "old" and the "new and improved" implementation if the intent is to be able to reliably revert that part of the system to a different implementation.

...I know this is doable for a reasonably experienced and skilled developer. I've worked in the logistics industry for several years and I've seen numerous home-grown barcode scanning systems designed and implemented by small teams (1-3 developers). Look at PointeWare (http://www.pointeware.com) as a starting point for a reasonably priced hardware + java api solution. It works with existing Motolora hardware which is easy to use, well supported, and cheap.

Still, unless you see an opportunity to do something that hasn't been done and you think there is a market to sell your system to additional customers OR your client is /very/ patient or taking this project on as a semi-charitable engagement then seriously think twice about doing this on your own. I've learned that barcoding, while a nice idea, is one of the finickiest and error prone technologies out there. Remember that barcodes are printed on paper and usually involve some degree of human intervention to match the right barcode on the right product. Barcodes are physical objects and are prone to damage and wear. The data capture mechanism is semi-manual which is also error prone. While your product may work well in the lab it is almost certain that you will run into unforseen problems dealing with things like:

1. symbologies - not all barcodes are encoded in the same format
2. encoded data - not all information on all barcodes are the same - some are EIN numbers, others are SKU's, and on and on
3. hardware incompatibilities - barcode scanners are NOTORIOUSLY unreliable and the manufacturers are notoriously bad at fulfilling orders
4. programming quirks on limited memory devices - forget about indexed databases - even commercial products like M$ PocketSQL quickly become major bottlenecks in performance
5. concurrent use locking nightmares - your system will require either real-time wireless communication with an in-store server or a sophisticated offline locking strategy to ensure data integrity when dealing with concurrent users. Yes, it's likely that there will be more than one user scanning data at one time

It is very likely that this system will be a huge time sink and financial loss for you.