A software smell is any property of code/design/architecture that HINTS at a deeper problem — a symptom, not a defect. Smells are subjective, language/method-dependent and overlapping.

Code smells (hint at problems), design smells (violate a principle), architecture smells (undesired structures).

Catalogue: large class & long/complex method (→ spaghetti code); blob / god class (one class controls many data classes, violates SoC/cohesion/SRP); long parameter list; alternative class with different interface; shotgun surgery (one change touches many classes); code clones / duplicate code; dead code; feature envy (a method uses another object's data more than its own); cyclic hierarchy/dependency; middle man; missing abstraction; poltergeist.

Facade vs blob: a facade defines a minimal interface with no behaviour of its own; a blob centralises behaviour and data.

Refactoring changes a system's internal structure to make it easier to comprehend, maintain and modify WITHOUT changing its observable behaviour. Technical debt is the future rework caused by poor design.

Because behaviour is unchanged, fixing a bug is NOT refactoring (it changes behaviour).

Technical debt: long-term negative consequences of design chosen for short-term benefit; accumulates 'interest' (gets costlier over time). Causes: deadlines, poor planning, no defined process, not adopting best practices, inexperience, outdated docs.

Fixes for smells: separate concerns, extract classes/methods, introduce inheritance/interfaces, apply MVC, apply established patterns (strategy/template), rename, move methods/parameters.