How Teams Build Software

When you use an app, it's easy to picture a single clever person who sat down, wrote it, and finished. That picture is almost never true. The apps you rely on were built by groups of people, changed over months and years, and they're still being changed right now.

This topic sketches that reality — software as a team effort that never quite ends — because it's the thing that makes the next few topics, and a whole stack of later courses, finally make sense. Once you see why building software with other people is hard, you'll see why so many tools exist just to manage it.

Many developersa whole team

→

One shared codebasethe source of truth

→

Evolving softwarenever finished

Many hands on the same code

A real app is too big for one person. The app on your phone might be hundreds of thousands of lines of code — the written instructions that tell the computer what to do — far more than any single person could write, remember, or maintain alone.

So a team builds it. Different people work on different parts at the same time: one person on the login screen, another on payments, a third on the part that talks to the server. They aren't taking turns; they're all working in parallel, every day.

That word for the whole body of an app's code has a name worth knowing: the codebase. It's all the instructions for one piece of software, gathered in one place. When a team "works on the codebase," they mean they're changing that shared pile of instructions together.

Software is never finished

Here's the part that surprises most people: an app is never truly done. The version on your phone today is not the version from a year ago, and it won't be the version a year from now. Software keeps changing for as long as anyone uses it.

It changes because the world around it changes. Users ask for new features. Mistakes turn up and need fixing. A phone gets a new screen size, a new rule arrives, a security hole is found. Each of those is a reason to open the codebase and change it again.

So "building software" isn't a one-time act of creation. It's an ongoing activity — a team returning to the same codebase week after week, adding, fixing, and improving. Keeping that in mind reframes the whole industry: most of the work isn't writing a program once, it's tending one that's already alive.

One shared codebase, one source of truth

If a dozen people are all changing the same instructions, there has to be one official copy that everyone agrees is the real one. That official copy is called the source of truth: the version the running app is actually built from, the one that settles any argument about "what does the code really say right now."

Everyone works from that shared copy. A developer takes the current code, makes a change, and folds it back in so that their work becomes part of the one official version. The next person builds on top of that. Bit by bit, the shared codebase grows out of many small contributions.

The problems this creates

Working this way solves the size problem but creates new ones. If two people change the very same line of code, whose change wins? If someone's change quietly breaks a part they never touched, how does anyone notice before users do? If everyone is editing the one official copy at once, what stops them from overwriting each other into chaos?

Think of a group writing one book together. Everyone is assigned chapters, but they all share the single manuscript. Without rules — who edits what, how edits get combined, how you keep an earlier draft — two authors will eventually rewrite the same paragraph in different ways, and the book becomes a mess. The team needs a system, not just goodwill.

Software teams hit exactly that problem, and the rest of this chapter is about the systems built to solve it. The need to track every change without overwriting each other leads to version control, the subject of the next topic. The need to check changes and deliver them safely leads to the testing-and-shipping idea after that. Those tools didn't appear for fun — they're answers to the mess that "many hands on one codebase" creates.