Add slides on the cost of adding dependencies

Đọc 04_dependencies_ci.qmd quanh phần mở đầu Dependencies và Dependency resolution, sau đó xem lại group_work/04_module.md để tìm Q3 hiện có. Thêm nội dung được đề xuất về các đánh đổi của dependency vào vị trí đã chỉ định, tùy chọn thêm câu hỏi tiếp nối, và xác minh rằng module đã render trình bày các slide mới một cách nhất quán.

Module 04 introduces dependencies and how to manage them with uv, but doesn't discuss the harder question: should you add this dependency at all?

This is especially relevant for scientific/engineering packages where a single poorly chosen dependency can make installation painful for end users (think compiled C extensions that won't build on a colleague's Windows laptop).

The two camps

In practice, teams tend to fall into two extremes:

1. "Not invented here" — rebuild everything from scratch, avoiding external code even when well-tested libraries exist. This leads to buggy reimplementations and wasted effort.
2. "pip install whatever" — especially common with junior developers, grabbing packages without considering licensing, long-term maintenance, or what you're pulling into your dependency tree.

Neither extreme is right. The goal is to make deliberate, informed choices about each dependency.

Suggested slide content

A new slide section in 04_dependencies_ci.qmd, after the current "Dependencies" intro and before "Dependency resolution". Suggested bullets:

• Every dependency is a trust decision — you're shipping someone else's code to your users. In 2016, an npm developer unpublished a tiny 11-line package called "left-pad" and broke thousands of projects worldwide, including React and Babel. Your water model shouldn't stop working because a string-padding library disappeared.

• Transitive dependencies add up fast — adding one package can silently pull in dozens more. Each one is a potential point of failure — version conflicts, broken releases, or abandoned maintenance. Run uv pip tree to see what you're actually shipping.

• Supply chain attacks are real — malicious code has been injected into popular packages (npm's event-stream, Python's ultralytics on PyPI). The more dependencies you have, the larger your attack surface. For packages used in infrastructure or safety-critical modelling, this matters.

• Check the license — not all open-source licenses are equal. GPL dependencies can force your entire package to be GPL. Some licenses restrict commercial use. Always check before adding — your legal team will care even if you don't.

• Consider the maintenance horizon — will this dependency still be maintained in 3 years when your model is in production? Check: How many maintainers? How recent are the releases? Is there a bus factor problem? For scientific packages, also check: does it require compiled extensions that complicate installation?

• When NOT to add a dependency — if you only need one function from a large library, consider copying the logic (with attribution). If the functionality is 10-20 lines of straightforward code, just write it yourself. Your future self debugging an install issue on a server will thank you.

• When TO add a dependency — don't reinvent NumPy or pandas. Well-established, well-maintained packages with large communities (numpy, scipy, matplotlib) are safer bets. The key question: does this dependency solve a genuinely hard problem that would be error-prone to implement yourself?

Placement

Between the current opening slide ("Dependencies are other pieces of software...") and "Dependency resolution" in 04_dependencies_ci.qmd. Could be 1-2 slides titled something like "Should you add this dependency?".

Group work tie-in

Q3 in group_work/04_module.md already asks about conflicting dependencies. Could add a follow-up: "Have you ever regretted adding a dependency? Or avoided one and regretted reimplementing it yourself?"