at DDD Europe this year I had the opportunity to attend Felienne’s talk “AI made me doubt everything about programming”, and it’s probably the first time I’ve seen a standing ovation in a tech talk, which was even more surprising after everyone in that room had just been criticised.
she defended the idea that in software development there is a tendency towards “complicatedness”, as if the validity of something is directly related to how “complex” it is, and at some point even threw the ball to us: aren’t you all in a conference about a set of techniques that could be reduced to “talk to your customer”?
we overcomplicate things, hell, one of my days at the conferences was full of theory and talks about complexity, so then is DDD also the over-complication of a simple concept?
from my point of view, these techniques and methodologies help bridge the gap between developers and the domain: between the technical world we operate in and the human world the software is meant to serve. they help us stay closer to the problem by turning reality into a first-class citizen of our day-to-day, making it harder to detach ourselves from the problem we are solving, since we are forced to connect to it through language all the time.
those techniques also palliate the lack of a common language to specify user needs in an approachable way both to the user and the developer; nonetheless, those techniques and tools are created and needed by the developer to be able to create more realistic systems — which might have been unnecessary if we had focused more on communication / understanding from the start of our careers, and not as a side-effect of complexity, a complexity that we built ourselves.
we have a history of choosing complicated solutions for simple problems, or dismissing others’ capabilities and opinions based on the technologies they choose to use. nowadays, schools like mine (42) are more focused on communication and collaboration, but they’re still too focused on developer-to-developer communication.
At no point during our education, do we stop to think about why we are solving problems, for whom, and you’re regularly incentivised to complexify things for the sake of “bonus” points, instead of focusing more on the minimum viable solution that solves the user needs. The idea that you’re solving human problems doesn’t come up until you actually go into the world.
people are moving to calling what we do “socio-technical” software design, to distance themselves from technical solutions that don’t take into account the reality of the problem they are solving, and the DDD community is simply people that have realised that what we build doesn’t matter as much as why we build it and for whom we build it, in a way, is the industry attempted cure to the disease that our love for complexity is for that same industry.