One of the hardest things about shipping products is balancing this contradiction: you want to do the best possible work everywhere, but optimizing every piece takes time, and time is finite.

I’ve done a poor job here countless times in my career. And I have seen many others struggle here, too. If you like your craft, it’s natural that you want to do your best all the time. But the best and good enough are different things: you must learn when and where to aim for each.

This is easy to understand, but it’s very hard to put into practice when it is time to do the work. How do you convince creative individuals who love building things to build less? How do you get someone who enjoys technical challenges to try to make things simpler and more boring? There is a joke about never asking a surgeon if you need surgery. What about asking developers if they need to build the perfect interaction, abstraction, or library? Of course they do!

I believe the solution here is not about good practices or coaching. Instead, it’s about creating a working environment that makes costs a first-level concern for those doing the work. Aiming for good enough won’t happen as an intellectual exercise in the abstract but out of pure necessity at execution time. 

How can you create such an environment? With constraints! I’ve seen 37signals apply these two consistently:

First, timeboxing. Time is not infinite, so don’t pretend it is. Set a deadline and give people doing the work the power to adjust what’s built. Fixed time, variable scope is probably the single most powerful concept I have ever learned about shipping.

Second, scarcity. Tiny teams that want to ship need to make the most of their time. Why would you restate problems to simplify them when you have an army of colleagues to work on whatever is pending to ship? On the contrary, how won’t you do it if shipping depends on completing a long list of additional things on your plate? The specific team sizes will vary, but I believe the principle prevails: a sense of scarcity helps shipping.

It may sound counterintuitive but consider the alternative. If neither time nor development bandwidth is a concern, how could people doing the work make the right call for the millions of decisions ahead?

When it comes to shipping, constraints are not to be avoided or resisted but rather embraced and even induced.

---
This article was originally published in the 37signals dev blog.
jorgemanrubia.com