Working with constraints isn't a new idea. It's not even a new idea in terms of software development. Back in the (relatively) early days of Microsoft they would only hire 3 people for a job they thought they needed 5 for. They did this because they found the solutions these teams came up with tended to actually be better solutions with an added benefit of having more autonomy. This was because the team had to focus on the key parts of the problem as they didn't have time to solve everything.
You of course don't just see this in the software world. The sport of basketball actually has a prime example of constraints in practice. The sport has never been known for it’s inventiveness. It took them 20 years to put a hole in the bottom of the net. Up until then every time a team scored someone would have to retrieve the ball from the net. Even so players stuck with it.
Back in the early days the National Basketball Association had problems attracting fans (and positive media coverage). This was largely due to teams running out the clock once they were leading in a game, teams passed the ball nearly endlessly without penalty. If one team chose to stall, the other team (especially if behind) would often commit fouls to get the ball back following the free throw. Very low-scoring games with many fouls were common which lead to bored fans. The most extreme case occurred on November 22 1950 when the Fort Wayne Pistons defeated the Minneapolis Lakers by a record-low score of 19-18, including 3-1 in the fourth quarter. The Pistons held the ball for minutes at a time without shooting (they attempted 13 shots for the game) in order to limit the impact of the Lakers' dominant George Mikan.
The thing that solved all this was the shot clock. This limits the amount of time a team has before they have to take a shot. It first came in to use in 1954 in Syracuse New York, where Syracuse Nationals owner Danny Biasone experimented using a 24-second version during a scrimmage game. The rest as they say is history with basketball becoming one of the biggest sports in America.
Another real world example of constraints can be seen in the world of medicine in constraint induced therapy. The concepts behind this were developed nearly a century ago when researchers realized that after a nervous system injury that impaired movement of an arm, experimental monkeys consciously avoided the use of that arm and preferentially used the “good” or intact one. You can see this when patients today are told to switch a patch from good eye to bad eye to improve it so that it brings eye up to speed
Another example that might appear much less obvious is that of analysis paralysis. Companies found that when they offered too many pricing plans that they saw a decline in the number of customers signing up. This was all because that customers had so many choices to make that they never ended up making a decision. When companies constrained the pricing plans down to three options they found that customer conversion picked up again.
This all boils down to using fewer resources to create better things. Obviously this only works if you truly are constrained. In a software team if you constrain the number of people but let the time they have on a project slip you'll find that the benefits you might have found by constraining one factor are quickly lost. Obviously it goes without saying that this needs to be done carefully. You don't want to constrain your resources so much that a team feels under such pressure and stress that it has a detrimental effect but if you get the balance just right the benefits have been shown again and again.
Of course if you dig down into it a lot of the practices and principles in software development actually encourage similar constraints for you. The practice of breaking large epics down into small stories means that if you do it right you're constrained to solving just a small part of the large problem. Standardising an architecture means that teams don't have to make so many decisions to make on the next project that they pick up.
So next time you pick up a piece of work try to think about how you can constrain the problem you're trying to solve. You might find it helps. I think Marissa Mayer summed it up pretty well in her Google days with "Constraints shape and focus problems and provide clear challenges to overcome".