Anti patterns in software architecture
This is the third article of a series. If you are interested in reading up on the previous ones, please check them out:
Architecture is a topic which is challenging to cover. Many principles applied in architecture depend heavily on their context, making it very hard to determine if it is an anti pattern or not.
Nevertheless, there are some things you should know how to spot, in order to avoid them.
Anti pattern
Big ball of mud
The big ball of mud is a piece of software without any recognisable form of software architecture applied to it. While the reasons for that can be various it often goes back to a lack of experience of the engineers involved.
Software architecture and design must be learned, kept in mind and exercised regularly. It is also quickly thrown overboard when implementation teams are pressured too much.
Big ball of mud systems are not welcome anywhere, and yet they can be witnessed all around the place. Those systems though are not necessarily inadequate. They often work, fulfil their purpose and are used. The problem is, that they only can be operated and maintained with enormous costs, and at the same time, it can be close to impossible to extend them.
Gas factory
This anti pattern describes a piece of code that tries too hard. When the task at hand is to solve a simple problem, with an easy solution and the engineer goes way over the top. Applying several design patterns, allowing for options and capabilities that have not been specified in the first place.
It is not really the Swiss Army Knife anti pattern (see anti patterns in software development), it is rather a completely overengineered piece of software that just tries too hard.
One of the main problems is that the best software designers are the worst offenders. Try not to put all your ambition into one simple piece of code.
Inner platform effect
The tendency of creating a system that is so very much customizable that it becomes a replica of the software development platform that is used. Mostly poor replicas.
One very prominent example is data models which abstain from using application-specific database tables and instead work with general tables as a common management layer for data structures with the goal in mind to increase flexibility.
The past has shown, that those systems are tough to handle and often result in performance problems, additionally. This pattern is tough to spot before it is too late. It helps to generally think about solving specific problems and have generic solutions emerging from those, and not the other way around.
Spaghetti code
One of my professors at university put that very well and precisely: “Imagine you pull one spaghetti on one end, and instead of having that one piece of pasta in your fingers you get a whole ball of spaghetti and with sauce and everything. That’s not what you wanted.”
That is pretty much what spaghetti code is. You cannot really trace where one spaghetti is going and where it is coming from. It is an entangled construct of software pieces. But, at the same time that does not mean it is broken software.
Probably somebody “just got started already”, instead of following clear design patterns and refactoring habits. It is one of the opposites of clearly structured source code and decreases maintainability, increases test and maintenance costs and will be tough to reuse.
Sumo Marriage
When a fat client is deeply married to a fatter database and the whole situation becomes too rigid and inflexible for growth. The fat client is unnaturally tough depending on the database.
Often you will find a lot of logic in database-owned programming languages like PL/SQL which renders the whole architecture very inflexible.
If you’d want to move that application towards the internet you’d probably need to rewrite the app since the client layers rarely can run in a server mode. Divorcing business logic from the database, and decoupling the presentation tier and business model are good practices for a reason.
Integration databases
An integration database is a database which is utilized by multiple applications directly at the same time to make sure some level of synchronisation can be achieved.
“Integration databases — don’t do it! Seriously! Not even with views. Not even with stored procedures.” — Michael T. Nygard: Release It!
An alternative can be provided by a shared database, which at least is wrapped in a singular web service which is used to connect applications to that database.
I hope you could find some useful information in those paragraphs and it can help you avoid some problems. I specifically left out “The Blog”, or the “God Class” since that has been covered in non-architectural anti patterns already, while that is disputable if that was right :)
FYI: if have put in a link for “Release It” on Amazon.
