The architecture of your application is important and you should be able to detect a bad one. I have been worked with bad architecture in the past. And with that I learned from those failures and what mistakes not to make. It’s important for any software developer to know how to detect a bad architecture is. If you can do this, then you are able to do something about it. This is the first step to creating a good architecture.
Decisions are taken to early
Often we take decisions to early in a project. We decide to early how our application will work and what libraries to use. At the beginning we should not focus to much on the low level parts of the system. We need to focus on the business logic. The UI and database are details and are not important at the start. They should be easy to change. A good architecture allows for an easy way to change those details.
Hard to change
When requirements change we need to hack those changes into the application. In some situation this causes a painful redesign of the system. Or in some cases we make it even worse when we are on limited time and budget. We add layer and layer of bad and dirty code. The best architecture is one which allows changes to be easy. Your business logic code needs to be in charge and be the one that is easy to change. It should not be your framework that decide this. This is a mistake a lot of people (including me in the past) make when creating applications. Your framework should not be the one dictating how your application works, the business logic should do that. The framework itself is a detail.
Centered around the database
The database is only a tool. A low level tool. Your application should not depend on it. Your business logic should not need to know about the database. You should not treat your objects and structure in terms of the database. You should not directly let business logic communicate with your database. There needs to be a layer in between. What database you use should not matter. The database should not be the one deciding how the business logic works. It only holds the data.
Business logic is spread
In bad architecture your business logic is spread across all layers. Its hard to find out how something works. Its one big mess. The whole application has business logic all over the place. And then because of this it might even be duplicated in your code. Making a business logic change on one place might cause instability and issues in another part of your application. Your business logic should have its own place. It should not be affected by details.
Hard to test
Most applications with bad architecture are hard to test. Everything is so coupled that one change here breaks something there. There might even not be any unit tests, because they are impossible to make. This application costs everyone many time to debug and maintain. You will get grumpy customers complaining there is always another bug.
Conclusion
Its your job as a software developer to make sure the architecture is good. If you see a bad one, then you should do something about it. Talk with your colleagues and try to solve it. Everyone makes mistakes, you and your team need to adapt and learn from them. Its not only important to think to code, but its also important to think about your architecture.