But what about complexity? Can it be defeated? We sure are trying. Every other week there is a new programming language claiming to reduce it, every other day a new framework to make storage, networking, rendering or communication easier than ever before.
Technical solutions are unessential
One could think that if this trend continues, writing software might one day be as easy as 123. But these are all solutions to technical problems and while they receive a lot of attention, I consider them unessential. There are many ways to solve a certain problem with software. Many different languages and frameworks to use. Each with their own benefits but also own drawbacks, like added complexity.
Think outside of technology, think in terms of domain
Outside the technology lies the conceptual space of the problem you are trying to solve with your piece of software: the domain. If you are creating a jump-n-run game, your domain includes physics, didactics and game design. If you write a restaurant management system, your domain consists of tables, orders and bills. Whatever kind of software you write, you will have to deal with the domain and its complexity. It cannot be avoided.
This is why in my talk Rapid Prototyping with Domain-Driven Design I claim that complexity is essentially in the domain.
Visit our IPC ’17 Sessions with a focus on Testing & Quality
Defeating unessential complexity
My personal hope is that it is possible to build a software development tool that avoids all unessential complexities. With such a tool, everybody could solve most of their own problems themselves. It could lead to a general software literacy, enabling people of every trade to take advantage of the full potential of computers, without depending on a tiny fraction of the “elite” to solve their problems for them.
Without technical complexity to conquer, software creators could completely focus on the domain. Instead of battling with encoding and databases, programmers could spend their time on understanding the world and forging their insights into dynamic models.
But we are not quite there yet. The tools we use are still complex enough that they require weeks of training before you can write software that solves even the simplest of your problems, let alone the harder ones. So you don’t need to worry that your knowledge of the newest JavaScript framework becomes obsolete soon. Our jobs are safe yet.
We still need professionals for creating and maintaining every tiny bit of software but because engineers have an inclination towards technical problems, we tend to neglect the domain.
If we accept that technical complexity is essentially in the domain, we can start to avoid technical complexity and focus on the essential problem, the domain. And this is the very premise of Domain-Driven Design.
