[goblin89]

Even with a single mind having the final say over the design, it is still easy to violate conceptual integrity in software if it directly or indirectly touches the end user or “real world” in general. In this case, requirements or their understanding will inevitably change, and any time that happens in order to maintain conceptual integrity software has (effectively) to be redesigned[0].

If you’re lucky, the result of that redesign might turn out to be close enough to what you currently have[1]. What’s dangerous is skipping that taxing redesign process altogether, or losing sight of the new target while you strive to maintain software built on the now-outdated conceptual model in order to address users’ current needs faster. Keeping in mind the updated model and evolving the whole system towards it while continuing to provide functional software to existing users at all times is probably the most difficult aspect of building software for the end user.

That said, I agree that originating from a single person (or indeed very few “agreeing resonant minds”) might be a pre-requisite for cohesive design, and I think “conceptual integrity” is a very fitting term.

[0] This might sound drastic, but this is my belief so far. Slightly expanded on it in https://news.ycombinator.com/item?id=25408650.

[1] I am tempted to say that the “tighter” the design (the more tailored the solution is to the problem), the more likely a small change in requirements is to affect the product in a major way once you rethink it.