Some months ago a manager referred to an existing method as ‘brittle’. I knew the standard definition to the word and inferred the meaning in this context but only afterwards have I settled on what it really means for software to be brittle.
Software becomes ‘brittle’ if too many assumptions have been made; “It will never be run on anything less than 1024×768 resolution”, “The user knows to enter the numeric serial number here”, “The quantity is never zero”, “We expect no more than ten users at any given time” and so forth.
Brittle software usually works just fine, or at least it does in the beginning or without too much extensive/excessive use. The load piles up, the users try unusual stuff, sometimes then the cracks start to show.
Robust software, on the other hand, makes the opposite assumptions; “We have to check the resolution of the display”, “The users may enter the date incorrectly”, “The database can contain anything (or nothing) in any column”, “The connection may drop at any time”, “The user may run the process for days on end”, etc. Hard coded values and factors are a common source of brittleness.
You have to actually pay attention to the stated requirements and look for actual real-world shortcomings. And that is how you make resilient software.