By Mattias Holmqvist - October 9, 2017
Another day at a random large software company in Sweden.
No one really knows how it works. The consultant who wrote the calculation routine quit 8 years ago (leaving a big mess) and now we need to handle this new law that’s being put into action this year.
One of the most important customers just found a serious bug in the reporting tool. The stats are way off and they can’t tell how they got to where they are now. It’s all very confusing. One of the senior developers spent a couple of days trying to reproduce the bug on a local server, then ran a bunch of complicated queries against the production database to find that it’s impossible to understand what happened. Hope it doesn’t occur again.
The gigantic ball of mud is being carefully tended to and nourished by dozens of software development teams, all of which are trying their best not to break the 35 minute build or the integration tests that are run every night.
The system got too big and too complex. It got to the point where people aren’t sure about what the system really does, or even why.
Sometimes, our software systems are nourished and tended to as if they were children that should be raised for at least 18 years to come.
I know nothing about raising kids, but I can surely tell you something that holds true for almost all companies: your software won’t last 18 years.
Your system will break down and stop working long before you even get a chance to send it to school. Technology moves fast. The world is right now somewhere in the middle of a hockey-stick shaped development curve and nobody knows what comes next. What we do know is that change will happen. Embrace it.
We care too much about our software. One of the best developers I’ve worked with used to say that software is supposed to be soft. Not soft as in easily-squished or cute, but rather mouldable and easy to grind down to its simplest possible piece. So that it can be easily changed or moved around to fit the problem it needs in times of change and adapted to changes in technology.
It’s true that knowledge about our domain or problem is often hidden inside our complex and large software systems. But remember that the software is merely a tool that we can use to bring our users joy during a certain task or to solve a difficult problem for our customer. Without our systems, the problems and user journeys around us would almost certainly exist anyway.
Often we get distracted into thinking that our software and the problem it solves is the same thing.
The greatest asset of your company is the accumulated knowledge about your domain.
Your domain model is the unique interpretation and solution to the problem that your company solves. This should be small and focused around a core, which is the most important facet of the problem domain. It’s the part of the company’s business that makes it unique, the thing that you know more about than any other. Your competitive advantage.
Your greatest asset is your knowledge about your domain
A company that has a better understanding of the problem domain and their customers can describe their domain and problem without relating it too much to their product.
“In designing a large system, there are so many contributing components, all complicated and all absolutely necessary to success, that the essence of the domain model, the real business asset, can be obscured and neglected.” - Eric Evans
Once we capture the knowledge about our problem in this way we have an incredible freedom to use whatever tools we like to bring the best possible solution to our customers and users!
How do you capture the knowledge that is there?
A lot has been said about this and I think that my biggest influence in this regard is without comparison Eric Evans through his book Domain-Driven Design. Use whiteboards. Use the language people speak in your organization. Ask questions, listen to people, write stuff down. Figure out what it all means.
A new interesting way to capture the knowledge about your domain that we have been using for a while is Event Storming. It is a very powerful and fun way to work together to figure out which problems your company actually solves.
So, try to zoom out. Work with your peers that are not developers. Talk to them about business events. Learn about something you didn’t know about that they hear when they talk to your customers or that they cannot do with your software today. You might get that breakthrough.
After a number of years of consulting around DDD, Event Sourcing and CQRS, we created Serialized to make it easier to develop software around business events. We’re all about helping you focus on your core domain and supporting you to build awesome systems.