How to approach the choice of architecture in the project

I started my career as a software engineer 15 years ago. I was working for an advertising agency at the time. Some orders we had to perform really quickly-sometimes even for yesterday. This made there was no time to discuss what approach to choose. Everything just had to look nice and be done on time. It also taught me something important. Many of you may disagree with me, but I will try to make this as clear as possible.

The truth is, nobody cares about best practices if the code is never used again. So let’s move 15 years later. I’ve been working as an engineering Manager for a few years now, and I keep seeing people recombine a solution to the point that they themselves do not know how to use this code in the next project.

And that brings us to the point where we need to talk about overgrown architecture. Over the years, I began to attach importance not only to the technical side, but also to the business side. It made me realize certain things when it comes to both aspects of software engineering.

Management decisions do not make any sense for developers, and requests from developers seem ridiculous from a business point of view. Of course. business wants software engineers to use as much code as possible from previous projects so that they don’t have to create too much new stuff.

Developers will always argue that the current requirements do not fit into the architecture, so you need to make changes to the basics of the project. And that’s how we got to the bottom of the problem. If every time we reuse code from some project, why do we need to update the foundations of our architecture? The answer here is quite simple: we are not able to predict the future, so there is no need to create software that will solve every possible problem.

Here is a very simple comparison: when we build a building, the architect plans the construction based on the specification of the request, that is: x number of apartments and Y, that is the amount of commercial space, etc. So one living space is rented for a burger joint, and this one modifies it for itself, regardless of who may occupy this space in the future. Why not try the same thing when we create software?

The software architecture is the foundation for a certain type of project-and that’s enough. We don’t have to worry about all the add-ons that might come along if our current project doesn’t require them. My recommendation is as follows: use an architecture that fits the project in its current state, not in the future.

The best decision about architecture is one that you don’t have to make – Robert C. Martin

Of course, there are companies like Facebook, Google, Amazon, which have millions of users and scenarios to predict, so their architecture will inevitably be huge. However, most developers work for smaller companies that have a single product or service-in such cases, the simpler the better.

The moral here is as follows: no one cares about best practices if the code is not reused later.

You can read the original English text here.