I'm learning how modern software is put together, and I'm surprised by how large many projects become. Even an application that seems fairly focused can contain tens of thousands of files, much of it coming from direct and transitive dependencies, frameworks, package managers, and generated code.
It feels like a small amount of project-specific code is sitting on top of millions of lines written by other people. Is this simply the modern norm, or are there development approaches that avoid this kind of complexity?
I'm especially curious about security: how do teams evaluate and trust all those dependencies, and how do they deal with vulnerable or breaking updates?
5 Answers
This has been common for decades, although the scale varies by project. When you download a compiled application, you usually don’t see its internal libraries as source files, but they’re still there in the form of DLLs, shared libraries, or bundled components. Modern package managers make the dependency tree much more visible, especially for ecosystems where applications include source and build files.
Dependencies are definitely a risk. A vulnerable, abandoned, compromised, or poorly tested package can affect every project that uses it, and transitive dependencies make the chain harder to understand. Updates can also introduce behavior changes, so teams commonly pin or lock versions, review upgrade changes, run automated tests and security scanners, monitor vulnerability advisories, and remove packages that aren’t really needed.
The file count can be misleading. A large portion may be generated output, test data, documentation, build artifacts, or libraries that the application uses but doesn’t maintain. The more useful questions are how much code the team owns, how many dependencies are included in production, and how difficult it is to make and test a change.
Yes, a lot of software is genuinely bloated, and legacy systems can grow for years without much cleanup. But large repositories aren’t automatically bad: reusable libraries can reduce duplicated work, and the real danger is unmanaged complexity. A small, carefully maintained dependency set is usually easier to secure than pulling in an entire framework for one minor feature.
There isn’t a magic way to trust everything. Mature teams maintain an inventory or software bill of materials, scan dependencies for known vulnerabilities, verify package sources and checksums, limit build and runtime permissions, and assign responsibility for keeping libraries updated. They also review important or security-sensitive dependencies instead of assuming that a popular package is automatically safe.
That makes sense for the size, but how have teams handled the security problem over all those years?