Like nearly everything in this imperfect world, software projects always fail for the combined effect of a number of reasons. But if I have to indicate just one reason behind failures–if not the primary reason, the root of all software evil–I’d point at requirements.
The point is not requirements per se; users exist and pay just to express what they think they want. And users–if left alone in the process–tend to accumulate tons of bulleted points regardless of order, relevance, common sense, applicability. It’s not the user to serve an ordered list of requirements; it’s you–the architect.
The good architect critically acknowledges requirements and challenges users. Sometimes you may find posts emphasizing the importance of saying “No” to users. Saying “No” is sign of courage but if “no” is said regardless it may sound outrageous.
How would you understand when it’s the right time to say “no”?
You must grab first the big picture of the system and the underlying domain. If you don’t get it, you hardly can question requirements. Or, if you do it, and users reply, then you’re stuck. So systems are built with an incoherent set of features. Worse yet, systems are built without a clear strategy and message and the UX is the first sign of limited effectiveness.
A decade ago, when DDD was first introduced, Eric Evans brought up the valuable theme of the ubiquitous language. Ubiquitous language was a way to push architects, users and stakeholders to use a common and business-specific language when talking requirements. By sharing a common vocabulary, all parties could point the same thing in the same direction reducing misunderstandings.
To me, today, ubiquitous language sounds more like a generic mild directive such as in the picture above the “easy to use” requirements. We need more concrete guidance in order to build a working set of requirements to turn into UX and logic. I’m not sure we find anything like this in DDD and its derivatives. Also because this is NOT the realm of DDD and its derivatives.
I dare say that the first step in a new, possibly right, direction is approving a sort of Copernican revolution in software architecture: why not starting your design from the presentation layer? Well done domain and business layers are key to have, of course, but UX and system design start from the presentation. If you start from there, though, you are forced to understand requirements correctly. And from there, you’re very well positioned for next developments.