Top 5 Software Architecture Mistakes

I have been involved in software and software architecture for quite a few of years, first as a consumer, then developer, then as an architect. I have seen lots of instances of good architecture and quite a few of utterly terrible architecture and associated systems management.

Below are what I consider my top 5 software architecture mistakes that I have seen in terms of adverse long term impact. I hope you recognise them and find them useful.

1. Pattern Perfectionism

You are likely to have come across this is if you have spent any time involved with software systems. This is where the design and the usage of OO techniques seems somewhat obsessive. Everything is defined in terms of the pattern it is based on as if the usage of the pattern makes it magically ‘correct’ and the Right Way? to be doing things, rather than in terms of the problem it is meant to solve.

Design Patterns, like any software structure have their benefits and their costs. Designing without due respect to the costs causes Pattern Perfectionism. Patterns if well targeted and used to solve particular structural issues can be highly beneficial, but if used all over they actually start to get in the way of system comprehension. Also most patterns come with an implementation overhead, that when blindly applied multiple times can soon become a crippling overhead.

2. Dam the Actual Cost

This is rather like the first point, but refers to when software design is done with little true regard to the costs of operation. In essence insufficient consideration is given to algorithmic efficiency, scaling and system utilization.

Now, in some cases this is valid mindset to have, especially when trialling a product or service, you want to minimise the cost in getting to something that can be used as a demonstrator. Although if you are designing a production ready system or framework, ignore the costs of operation at your peril.

Related to this is that often the human costs associated with a system get little consideration, you could end up with a beautiful architecture that has everybody tied in knots around it.

3. New Shiny Object Syndrome

I bet you’ve come across this one before. This is where a system designer or manager seems to be hell bent on using the latest and greatest technologies or methodologies regardless of the technology ‘pedigree’ within the business. I have seen this one alone cost literally millions in lost opportunities and increased costs as it just does not ‘fit’ with how things are done.

The real danger here is several fold:

• The technology or methodology could be unproven; there is little track record of it being successfully applied in the chosen field;
• The dependency tree of the technology could be wildly outside what the business supports, again creating more risks and costs;
• The net actual benefit could be ‘illusionary’ i.e. it might be cheaper to just use or fix what you have then tear everything up, and;
• Worst of all, it creates a technology ‘split’ within the business, i.e. those who use and love the new tech and those who loath it and go out of their way to avoid it.

Watch out for this one like a hawk, it can single handily undo all attempts at rationalising your architecture. Such new technology usage needs to be well planned and done with consideration to the whole business.

4. Crossing the Streams of QoS

Crossing the Streams of QoS (Quality of Service) is a little known but quite disastrous ‘blind-spot’ I have seen over the years and is actually becoming more common due to the increased usage of Cloud frameworks. This nasty architecture anti-pattern goes somewhat like this:

1. Business offers hosted service(s) to different clients, each with a differing QoS commitment;
2. The technology used to implement said hosted service(s) has at least one shared layer common across all the QoS bands;
3. Different engineering groups work on different hosted services with little awareness of what the other engineering groups are doing...

See what is going to happen? That shared layer in the middle somewhere is used by different products with engineering groups who have little awareness how everybody else is using said shared layer. What this means is if one engineering group at a low QoS does sometime destructive to that shared layer – it will impact adversely on other products at a higher QoS – hence the GhostBusters crossing the streams reference – very bad news all round.

I have seen (at a distance) this anti-pattern take out a whole shared service layer due to one run away script, costing a lot in lost goodwill and business. The solution is to keep different QoS layers physically separated always, which can be hard to achieve given the lack of awareness as to how a cloud service really operates.

5. Not Invented Here

Not Invented Here (NIH) is a biggie, I have seen businesses twist themselves into expensive knots with internal technical ‘turf wars’ of such complexity as to make Star Wars look like a school yard bust up. Literally multiple millions of time, effort and lost business opportunities have dropped into this bottomless pit and it will never fill up!

On the architectural side, this often presents itself on two levels; component and super system. On the component level an engineer will complain that sub-system XYZ does not do what we need, so before even talking to those maintaining XYZ will go off and do their own thing – the solution here (if you catch it in time), is of course to get said engineer in a meeting with the maintainers of XYZ and get what they want on the urgent To Do list.

On the super system, things get more ‘fun’. This is where inter departmental politics come into play and who is closer to the decision makers is actually more important in winning than the merits of each technology solution and actual current usage; particularly when those in management have little true comprehension of the costs of change and the time involved.

This can be particularly destructive to the long term unity of engineering teams and often results in a lot of time, effort and valuable contextual knowledge being thrown wholesale out of the nearest window – only to have to be learnt again by going through exactly the same problem set.

The way out of this is to have senior engineering managers & architects able to ‘go above’ the bun fight before it gets going and get a considered decision on what is the right path across the groups concerned. Hints: 1) no one side is ever completely in the right, 2) significantly value real direct experience over abstract 'new solution' experience or benefits.

BTW: I find the NIH mindset in this day and age particularly strange, given that vast majority of the software running on computers is written by others outside of the business - wouldn't you prefer to use software written by someone you can call or email directly if you have a problem?

I hope you have found my top 5 of use, if you have any comments or an architecture design mistake you would like to add please feel free to comment below.