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.

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

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

| improve this answer | | | | |
  • 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 Feb 18 '11 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 Heiler Feb 18 '11 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. – Adam Crossland Feb 18 '11 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 Feb 18 '11 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 Feb 18 '11 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.)

| improve this answer | | | | |
  • 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 Feb 18 '11 at 19:11
  • 4
    to me, ORM is architecture smell. – Christopher Mahan May 3 '11 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.

| improve this answer | | | | |
  • 1
    Interesting point, can you provide an example? – Travis Christian Feb 18 '11 at 16:44
  • Clever coding is code smell. – Christopher Mahan May 3 '11 at 21:08
  • An answer that makes a statement without supporting facts. Answer smell? – Evan Plaice Dec 13 '12 at 23:53
  • @EvanPlaice My apologies. Hopefully my edit provides some more insight into how I arrived at my answer. – Michael Brown Dec 14 '12 at 16:25
  • @MikeBrown +1 I was being facetious but nice improvement. – Evan Plaice Dec 14 '12 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.

| improve this answer | | | | |
  • 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 Feb 18 '11 at 14:19
  • +1 but YMMV. Use with caution. – Michael K Feb 18 '11 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 Feb 18 '11 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.

| improve this answer | | | | |

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.

| improve this answer | | | | |

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.

| improve this answer | | | | |

Your Answer

