> Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change This is not true. I've had require

> Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change This is not true. I've had requirements change on me before, and I alluded to this with one tiny phrase: > It can happen in two ways: the problem changes (your liability increases) or your software becomes less useful (your asset depreciates). (Emphasis added.) Code liability is directly tied to both the code and the problem. If the problem changes, including requirements, your liability increases. I still suggest that people design though; the act of doing so sometimes reveals flaws and ambiguity that can be worked through early, even if only partially. And design does help keep your mental model more correct.