Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
What advice would I give a software developer? Software development, design, and architecture can feel overwhelming. Especially when you’re just trying to get into it as there is so much to learn. What exactly should you focus on? A particular framework, language, or library? After over 20 years of software development as a career writing line of business and enterprise systems, here are the top 5 pieces of advice I’d tell my younger self.
YouTube
Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post.
Business Knowledge
If you’re writing Line of Business or Enterprise Software, having a good understanding of the business domain your writing software for is critical. This is why it’s perplexing to me that the software industry is so focused on frameworks, libraries, and platforms. Yes, technical concerns matter, but the sheer lack of emphasis on business concepts is amazing to me.
By far the best developers I know have a good understanding of business concepts and the specific business domain they are in. This gives them the ability to speak to a varied audience. From both spectrums, they can speak with domain experts all the way to other software developers.
Having experience in many different business domains only helps your understanding of designing a system. There is a common thread that generally is involved in most business domains that you can then relate to others.
My advice to my younger self is don’t get so caught up entirely on the technical aspects of being a software developer. I wish I would of put more focus on understanding various business concepts earlier in my carrier.
Logical Boundaries
The more you understand how various businesses domains operate, the better you can understand how to design a system by decomposing it into logical boundaries.
Defining boundaries is one of the most difficult things to do, yet is one of the most important.
When you don’t really know a particular domain, it’s like walking into a dark room with only a small flashlight. As you point the flashlight around the room, you get a better sense of how big the room is, what’s on the floor, how tall the ceilings are, etc. It takes time and it takes a lot of exploration to get a better perspective.
Logical boundaries own a set of business capabilities and the data behind those capabilities. Within a logical boundary, there are long-running business processes and workflows. These also might span multiple logical boundaries.
CRUD (Create-Read-Update-Delete) has its place, but not the heart of the system which generally has a lot of complexity. The outer edge of your system has boundaries that are more in a supporting role for reference data can often be CRUD or be an external system/service that you integrate with.
Define logical boundaries that isolate the business capabilities your system provides.
Coupling & Cohesion
Fundamentally understand Coupling & Cohesion. Seemingly every design decision revolves around these two concepts.
coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
cohesion refers to the degree to which the elements inside a module belong together.
https://en.wikipedia.org/wiki/Cohesion_(computer_science)
Circling back to the earlier section about defining Logical Boundaries is exactly about trying to achieve a high level of functional cohesion. Logical boundaries will have some degree of coupling because they will need to interact with each other.
Ian said it perfectly. It’s all about trade-offs.
Complexity
If you’re in a complex business domain, managing complexity can be difficult. But don’t make it even worst by adding unneeded technical complexity. This happens way too often by developers wanting to use new technology/library/framework without any idea if it solves a problem they actually have.
Complexity also comes in the form of logical boundaries as well as coupling & cohesion.
Defining logical boundaries is trying to prevent you from creating a giant turd pile (big ball of mud). Ultimately you’re trying to build a set of smaller turd piles. This allows you to isolate the complexity to a smaller logical boundary that is limited in scope.
As much as you think the system you’re building is going to be perfect, over time different insights and gaining new knowledge will mean that the overall design will be less ideal than you want it to be. And that’s OK!
Isolate complexity the best you can give your understanding at the time of making a decision. Understand that you won’t get it completely right. However, DO NOT add unneeded technical complexity because a discovered a new design pattern, library, framework, etc that you think will solve all of your problems. Also, DO NOT add unneeded complexity based on assumptions or “what ifs” that you think might be needed to make the system more flexible possibly in the future. Give yourself options but not at a high cost of complexity.
Know what you don’t know
There is so much to learn in software it’s pretty much impossible to know everything. However, it is helpful to have a surface-level knowledge or just be aware of the current landscape. That doesn’t mean you need to be an expert at all, rather the opposite. Just being aware of a new tool/framework/platform and the problems it solves can be really helpful if you find yourself with that problem.
The key is acknowledging that you aren’t an expert but rather only have entry-level knowledge.
Don’t be an Expert Beginner.
My software developer advice is to realize that there is a mountain of knowledge you just don’t have and that you don’t know what you don’t know. That’s OK! Don’t take yourself too seriously.
Join!
Developer-level members of my YouTube channel or Patreon get access to a private Discord server to chat with other developers about Software Architecture and Design. As well as access to source code for any working demo application that I post on my blog or YouTube. Check out the YouTube Membership or Patreon for more info.