This week I read a blog post from Robert Laszczak of Three Dot Labs titled “Software Dark Ages”. You can find that post here.
What was the article about?
Laszczak recounts his experience working for a company heavily ladened with pretty much every single kind of organizational, institutional, architectural, and technical flaw or burden out there. In his retelling, even something as simple as changing the functionality of a button would take months because of extremely high code coupling–among myriad other problems.
The way he solved this problem was to use DDD, or domain-driven design. DDD, like the similarly named test-driven development (TDD), places foci on particular problem domains and builds up around them. In TDD, these foci would have been our tests and test coverage, which we would then use to build up our code against. In DDD, we start with the problem and come up with a solution pattern that perfectly encapsulates the problem and its who/what/why/whatever.
If this sounds deceptively intuitive, that’s because it probably is. As Laszczak points out, DDD and problem-solutions like it have existed for almost two dozen years at this point (DDD’s whitepaper dates to 2003). The reason why they’ve fallen into obscurity is because people have forgotten the enlightened ideas of antiquity like they’re living in the Dark Ages.
In [the] Software Dark Ages, infrastructure is putting down important software design techniques.
The problem is, Laszczak bemoans, that the modern software DevOps team is more concerned with achieving technical marvels (e.g. getting that Atlassian Certified t-shirt) than spending their brainpower on something as simple as considering the wheel. Technology is great, except why are we using it? What purpose does it have, not only for us, but for our customers?
The reason we engage with structural criticism is to gain a better understanding of the system at play. Look at 432 Park Ave in NYC and you might see what a poor grasp of domain causes for a project, and when engineers are aware of the customer and their problems but choose to ignore both because… it was easier?
Why does DDD matter & why did I choose this post?
We have many frameworks for tackling software problems and organizing work, but very infrequently do we stop to consider the intricacies of the problem and how we can shape our project to meet the problem’s needs (inputs) rather than our organization’s abilities (outputs). Having high productivity and a strong team culture is important, but what does that mean if our codebase is in a terrible shape and our customer’s final product isn’t right-sized to their needs?
In our class, we’ve begun to work with Thea’s Pantry, and one of the things we’ve touched upon time-after-time is that the state of the system is specifically tailored to the needs of the pantry. Not all pantries–not a lot of pantries–the code we are looking at is the way it is because someone or something at Thea’s Pantry needed it to be that way.
That’s what thinking in terms of DDD yields us.
What not thinking about DDD yields:
- 432 Park Ave
- The Torment Nexus (NB DevOps: not an Atlassian product, don’t try it!!!)
What I think: DDD is a mouthful.
Kevin N.
From the blog CS@Worcester – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.