Hexagram 60: 節

The modern software development reflex runs: if you're hitting limits, add more resources. Out of memory? Add RAM. Slow queries? Bigger database. Build time too long? More powerful CI servers. This works until it doesn't. Here's what the classical text distinguishes: natural versus galling limitations. The Apple II's 48K was natural—the actual hardware reality that shaped elegant design. Wozniak's architecture squeezed maximum utility from those 48 kilobytes because the constraint was real and understood. An artificial limit imposed by decree ('you can only use 48K even though we have gigabytes available, because I said so')—that would be galling. Arbitrary restriction that produces resentment, not discipline. The test: does the limitation serve a genuine purpose and apply fairly? Memory constraints on embedded systems force efficient code—that's natural limitation producing better engineering. Arbitrary code-size restrictions imposed by fiat while management's pet project gets unlimited resources—that's galling limitation producing quiet sabotage. The text says 'sweet limitation brings good fortune,' describing the leader who applies restrictions to himself first. If you're implementing constraints, this is diagnostic: do you operate under them too, or only impose them on others? The former creates discipline. The latter creates rebellion and half-hearted compliance. The Apple II succeeded precisely because the limitation was real, understood, and applied universally. Every programmer had 48K. Nobody got special exemptions. The constraint shaped the design space, and within that space, excellent work became possible. Remove the constraint entirely—infinite memory, unlimited processing—and a different kind of work emerges: careless, bloated, inefficient. The lake contains a definite amount of water; this peculiarity gives it form. But: 'Galling limitation must not be persevered in.' Know the difference between discipline and arbitrary restriction. One produces the Apple II's elegant architecture. The other produces resentment and workarounds. If the limitation serves no purpose except control, people will route around it. If the limitation is real and shapes genuine possibilities, people will work within it and produce better results. The difference is whether the constraint creates form or just creates friction.