There are tons of resources on the web referring to and listing code smells. However, I've never seen information on architectural smells. Is this defined somewhere, and is there a list available? Has any formal research been done into architecture defects, and their impact on project speed, defects, and the like?

Edit: I wasn't really looking for a list in the answers, but documentation (on the web or in a book) about architecture smells.

  • 5
    Only when the architect has poor personal hygiene habits... Commented Feb 18, 2011 at 14:19
  • I really didn't meant for y'all to list the smells here. Maybe link to a list?
    – C. Ross
    Commented Feb 18, 2011 at 14:25
  • Ross Sorry I didn't realize that. I just added a few experiences. Commented Feb 18, 2011 at 15:20
  • @Amir Rezaei yours is the best of the lot, at least you consolidated your list into one post.
    – C. Ross
    Commented Feb 18, 2011 at 15:34
  • Architecture Astronatus
    – Laiv
    Commented Mar 22, 2018 at 7:16

8 Answers 8

  • Multitier Architecture When you have Layers on Layers on Layers on Layers... you see my point here, in your application. I call it Over Layered Architecture
  • Over abstraction in such way that you get lost in the code.
  • Futuristic Architecture This happens when the solution is too futuristic. In reality no one can predict new requirements. Therefore most of the futuristic implementation is just waste of time and resource.
  • Technology Enthusiastic Architecture The architect liked the new technology and he put in production. Without knowing if it was proven before.
  • Over Kill Architecture A simple problem was solved by exponential factor of architecture skills and technology.
  • Cloud Architecture I call it cloud architecture since architecture has no connection to the really. It’s just some nice Visio diagrams.

The total lack of the opposite is also true.

Here is link of Top Ten Software Architecture Mistakes.

  • 2
    I agree on this one, I've seen absurd layered application (up to 9 layers)
    – user2567
    Commented Feb 18, 2011 at 14:18
  • 7
    Baklava architecture?
    – Andrew
    Commented Feb 18, 2011 at 14:19
  • 15
    ah, the close relative to spaghetti code, I like calling this 'Lasagna Code'
    – GSto
    Commented Feb 18, 2011 at 14:21
  • 6
    Ooh @GSto - Spaghetti code in Lasagna architecture. The complete ensemble could be called "little Italy."
    – glenatron
    Commented Feb 18, 2011 at 14:33
  • 2
    In some places application_layers == (developers_assigned - 1) because someone ends up being the PM.
    – sal
    Commented Feb 18, 2011 at 16:05

Everything is Configurable. When an architect tells you that his system is change-proof or highly-customizable because of extensive configurability, that's an architecture smell.

The problem is that you can really only provide configuration mechanisms for what you think right now is going to need to be configured, but once your application is in the wild, it will not be sufficient. Then, the configuration mechanisms expand and expand, and eventually you get the Inner Platform Effect.

And then you are in software hell.

  • Interesting though, that the Inner Platform Effect is hellish and yet a lot of people are looking at DSL oriented development as a Next Big Thing, which is slightly inner-platformy by design I think.
    – glenatron
    Commented Feb 18, 2011 at 14:34
  • @glenatron: Maybe that's the point? Why not just throw in the towel and assume it's going to happen. Then you can develop with your DSL and modify implementation to deal with more configuration.
    – Jeremy
    Commented Feb 18, 2011 at 15:19
  • I would say that DSL is as DSL does. That are good ways and bad ways to implement. When I think of how it can be done right, i think of the many DSLs that make up Ruby on Rails. They don't implement their own language -- they are just constructs within a Ruby program, but they cleverly and helpfully abstract away many of the details of what they are a language for. Where the IPE really begins to stink to high heaven is when you move from Domain-Specific Language to Increasingly Generalized Lanuage that starts to look a lot like the language that it is implemented in. Commented Feb 18, 2011 at 16:17
  • I was reading about DSL's recently, Jetbrains have their MPS which looks interesting, but I can't yet conceive of using it. They claim to use it on some of their products, so I might inquire to see which ones and how.
    – Ian
    Commented Feb 18, 2011 at 16:29
  • I would upvote this 100,000,000 times if I could. If you have ever used the project management tool called Clarity you would understand why this is a horrible architecture choice!
    – HLGEM
    Commented Feb 18, 2011 at 20:31

A database designed by an ORM! Or a database backend that is nonrelational that should be relational. Or a database where you design to use views that call views that call views, not only are they too slow (databases must be designed for performance from the start not later) but when you need to make a change, they are horrible to track through (Over abstraction as @AmirResaei said makes it easy to get lost in the code when you need to fix something that is at the bottom of all those layers.)

  • This is dead on. Sadly, it's becoming a bigger problem as hardware gets faster. It works fast on 10 records, why wouldn't it work with 100,000,000?
    – Jeff Davis
    Commented Feb 18, 2011 at 19:11
  • 4
    to me, ORM is architecture smell. Commented May 3, 2011 at 21:07

Code smells and architectural smells are one and the same. Code begins to "smell" because of sub-optimal architecture.

In Martin Fowler's seminal book on the topic, Refactoring, he presents a series of Code Smells and identifies way to refactor them out of your system. Joshua Kerievsky's Refactoring to Patterns further emphasizes this idea by giving specific architectural patterns to fix various code smells (and how to refactor to them step by step).

Most refactoring is done to alleviate suboptimal code via enhanced architecture. One could argue that the only naturally born "Architectural Smell" (other than Big Ball of Mud), would be the BDUF (Big Design Up Front) Architecture. Where you try to accommodate everything you need before the first line of code is written. An agile software project where design is done as needed (even I daresay where code is treated as design), will have its architecture grow organically.

  • 1
    Interesting point, can you provide an example? Commented Feb 18, 2011 at 16:44
  • Clever coding is code smell. Commented May 3, 2011 at 21:08
  • An answer that makes a statement without supporting facts. Answer smell? Commented Dec 13, 2012 at 23:53
  • @EvanPlaice My apologies. Hopefully my edit provides some more insight into how I arrived at my answer. Commented Dec 14, 2012 at 16:25
  • @MikeBrown +1 I was being facetious but nice improvement. Commented Dec 14, 2012 at 19:58

(A lot of) Coupling -in whatever form- is what makes architectures smell. The more it's coupled, the more it smells.

That said : no coupling at all often smells performance issues.

  • 1
    I have to disagree with that. If you are talking business applications, coupling to a database that is highly unlikely to change is smart not stupid. You can use the more performance feature that are database specific.
    – HLGEM
    Commented Feb 18, 2011 at 14:19
  • +1 but YMMV. Use with caution.
    – Michael K
    Commented Feb 18, 2011 at 14:25
  • 1
    That's why I added "no coupling at all often smells performance issues". I agree that you have to use coupling to enhance performance. It's when there is a lot of coupling everywhere (between the different modules/classes/whatever of your application) that there is an architectural problem.
    – Klaim
    Commented Feb 18, 2011 at 14:26

Here's one concrete architecture/design smell that I encounter all the time: analysis and reporting directly from a transactional database.

This is certainly OK in some situations (i.e. light reports), but in many cases reporting and transactional processing requirements are in conflict. Yet, because it's the simple/inexpensive thing to do, reports are run directly off of the transactional DB. This causes all sorts of headaches on both sides of the equation.

This is typically seen in Enterprise LOB apps, btw. I understand that many SMBs just don't have the resources or know-how to create warehouses and datamarts (forget about cubes, or map-reduce setups), but many larger orgs that I've worked with have the same issues.

When designing a system, the architect really should be aware that reporting - especially analysis reports - and transactional requirements are best treated as separate issues and not just lumped together at the database level.


I'm not sure if this rightfully fits at the architecture level, but if I see a bunch of manager classes/modules in what is supposed to be an OO design then that is a guarantee that the only person who will understand the architecture/design is the architect/designer himself without lots of explanation/learning by others.


There are many architecture smells documented by the community. A commonly occurring set is the following.

  • Cyclic Dependency: This smell arises when two or more architecture components depend on each other directly or indirectly.
  • Unstable Dependency: This smell arises when a component depends on other components that are less stable than itself.
  • God Component: This smell occurs when a component is excessively large either in the terms of LOC or number of classes.
  • Feature Concentration: This smell occurs when a component realizes more than one architectural concern/feature.
  • Scattered Functionality: This smell arises when multiple components are responsible for realizing the same high-level concern.
  • Dense Structure: This smell arises when components have excessive and dense dependencies without any particular structure.

I recently prepared a taxonomy of smells. Currently, it documents 38 architecture smells and more than 260 total code smells.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.