Personal Catalogue: PHP & MySQL — Chapter 1, Exercise 1
====================================================

TASK
Explain why barcode scanning was deliberately deferred rather than built
into this first release, and what real project constraint drove that
decision.

SOLUTION

Barcode scanning is an obvious, genuinely useful way to add items to the
catalogue faster than typing a title by hand. It is not deferred because
it isn't wanted — it's deferred because this project has a real deadline,
and every feature added before release has to earn its place against
that deadline.

Manual entry (a form with title, format, author/artist fields) is the
minimum viable way to get items into the database. It requires no camera
access, no barcode-format parsing (UPC/EAN), no lookup against an external
product database (something like the Open Library API or a UPC database
service) to turn a scanned code into a real title and author, and no
handling for the case where a scanned code isn't found in that external
database at all. All of that is real, additional work — work that adds
delay without which a working catalogue could already exist.

Deferring it doesn't mean ignoring it. Chapter 9 of this course covers a
concrete plan for adding barcode scanning as a second phase, once the
manual-entry version is live and already useful. That's the real
discipline behind "nice to have, not blocking": ship the version that
solves the actual problem first, then add the feature that makes solving
it faster.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the real constraint (a genuine deadline) rather than a
vague "it's more advanced" excuse, names the concrete extra work barcode
scanning would require (external API lookup, format handling, a
not-found fallback), and points to where the deferred feature is picked
back up rather than treating it as abandoned.