While attending QCon last month, we happened upon a great talk from Matt Ranney, chief architect at Uber. His company has more than 700 internal microservices. This has come about because the philosophy at Uber is to let new engineers write new code, rather than dive into some old crusty software that’s been handed down from team to team.

This may sound crazy—it encourages the flourishing of hundreds of new software projects within an organization—but Ranney had some excellent advice to allow such a system to grow manageably. The key, he said, was to find the proper point for each service at which you can let it go. Counter to all traditional software development thinking, Ranney advocated for a state of “done” for a time in the development process where everyone simply forgets the service, documents the inputs/outputs, and moves on.

(Related: How Uber thrives in chaos)

When software was young, it made sense to continuously improve projects and applications: New features were the lifeblood of the ISV business. But at some point, we feel the industry lost sight of what the real goal is for most enterprise software: getting something done.

While new features sell new contracts, your old users that have gotten used to how your software works can be downright hostile to changes. Google, among many, is guilty of this, and will frequently change how its applications work, move functions around, or just outright eliminate things.

That’s great for the developers at Google who no longer need to support legacy code, but for the end user (that is, everyone who’d gotten used to that button being on the right, or that hotkey being over here), those changes can result in chaos, confusion and, worst of all, loss of speed.

There’s a lot to be said for those systems inside your organization that no one ever touches. They’re the ones that are “done,” upon which you can build a thousand new applications without fear of them breaking because someone is still stitching the rug they’re standing on.

So while Uber’s infrastructure—filled with more than 700 services mostly written in the last two years—may sound like a nightmare, it’s possible because the company has a philosophy of embracing the chaos. That may be counterintuitive, but frankly, when everything around you is pure chaos, it’s those systems that don’t change that provide the bedrock for future growth.