I have been thinking a lot more about the importance of software architecture over the last year. This started when I read Clean Architecture by Robert C. Martin.
Clean Architecture introduced me to think more about architecture. Because of this, I have been putting a lot more effort into thinking about software architecture over the last year. And it honestly has improved the quality of my work a lot. It’s not yet perfect, but I’m getting a deeper understanding of all these concepts the more I apply and use them.
The chapter that struck me and opened my mind and reminded me of the biggest struggles in my career. Was a tale of two values. Behavior vs Architecture.
Behavior
As an aspiring web developer, my first goal was to get my code working. It needs to behave like this and that. I don’t care about the future. I want to have it working now! Without wasting any time.
But you can get stuck in this mindset. We might think, that we are only hired to create software, based on some vague requirements. And that it needs to be done as soon as possible, and if possible yesterday. And then maybe, try to write good code.
So what do we do? We just get it working. And we try to write good code. But… When you try to write good code, you might start lying to yourself. This code works, it looks good. You are not really triggered to create exceptional code, to doubt if your code is actually good. Because why? It works right?
When you think that the only job you need to do as a developer, is to get the requirements working as soon as possible. You are not a professional.
Architecture
The thing with behavior is, you see its effects immediately. You create something, and it works. But architecture is the craft to make something easy to change.
If you create software without thinking about architecture, you create software that is developed fast, and hard to change. And you don’t realize this after the first, or maybe the second year in the project. But the longer you build on bad architecture, the harder it gets to make changes.
You might get stuck in this cycle. You think; that this is just how software works. It becomes increasingly harder and harder to change. More features get added. So more things you need to try to fit together.
Every feature becomes another puzzle you need to solve and try to fit into your program. It becomes a pain, you spend so much time to get it working. There is even less time to work on improving the architecture. You have created too much technical debt.
By the time you realize it, you created a big ball of mud. Then it’s too late.
A lot of software developers then go in denial mode. No, we did not create a big ball of mud. No, the code is good enough. It’s not that bad, right? We can improve it later…
Wake up! Think about architecture right now. Make your software easy to change now!
Overcomplicating
Another thing that I did in the past, and I still see a lot of developers do. Is to create overcomplicated code. You can make your code super flexible, making sure all possible future situations are thought of. But if it takes a lot more extra effort to create, and makes your code harder to read and understand. Then it has no use.
There is no reason to develop code for possible future uses cases or behaviours. Things can and will change, we are living in an agile world. It is impossible to know what features we actually need to build next month or next year. Things can and will change. That’s the nature of an agile world.
My golden rule is; write just enough code to get your code working now. Then try to make it more readable.
You will read more code then you write. It is thus more important that your code does just what it has to do, and is easy to read. Then it is easy to make those future changes.
To sum up
It’s not about just creating behaviour, but about creating quality code that is easy to change. Helping build the requirements to make a better product. Creating an architecture, building on it, to have a codebase that is always easy and flexible to change. A system that can easily evolve in the future. And will always stay relevant, whatever happens.
I learned from my mistakes in the past. I learned to always face the facts.
Don’t lie to yourself, don’t lie to others. Creating good software is a struggle. It’s your job to be a professional software developer. This means fighting for what’s important, fight for architecture. Fight for the thing you are hired, to create awesome software! To help build the requirements. Not just follow the requirements blindly.
First, build the architecture. Build systems that are easy to change. Then start building the behavior. And preferably do it in an agile way. This means, build just enough architecture to have just enough change to build just enough behavior. Repeat and retrospect. And remember, don’t overcomplicate!
Think before you code, fight the struggle and be professional!