top of page
Search

Software Architect: Bad Practices

Aka The Factors That Could Earn You a 'Golden Raspberry' in the Software Architect (SA) World


On hot, frustrating days, it's useful to compile all the potholes that have caused repeated stumbles in software architect. This collection of bad practices can serve as a guide for avoiding common traps, whether one is an SA, a Developer, or a DevOps professional.


Software Architect

Solving Problems Before Identifying Them in Software Architect


This is undoubtedly the first issue to be mentioned and one that should be kept in mind even while reading this article. Do you understand your purpose for reading this article? What is this article supposed to achieve?


Many people, just because of the title 'Software Architect,' hastily design an entire monstrous software system, incorporating trending solutions and technologies like Machine Learning, Big Data, AI, etc., without even identifying the problem.


Two critical questions must be answered before starting any design or construction are:

  1. What problem am I facing?

  2. Where am I in the product development process?

For instance, if the project is just a tech blog, setting up a micro-services system with dozens of small applications is unnecessary. If in a startup phase testing the market, a bulky system with many components is a no-go.


Here are some painful experiences from professionals:

  1. Launching a Niche Platform: Starting a platform in a niche market without understanding market acceptance or an effective business model, and implementing a micro-services solution with containers and cloud infrastructure designed to handle millions of bookings, only to spend a year on a product that could have been built quickly with a simple monolith or even a WordPress setup.

  2. Letting SAs Decide Features: Continuously adding features like voucher codes, online shopping, dropshipping, booking, affiliate marketing, etc., without ever releasing anything, resulting in constant feature churn and no actual product release.

  3. Over-engineering Relationships: Applying complex mathematical models without understanding the practical relationship between entities, leading to sophisticated but irrelevant solutions.

  4. Smart Content Systems: Designing high-tech systems with advanced models, only to crash when traffic slightly increases, a situation humorously called 'dying young.'

Overzealous Adoption of New Technology in Software Architect

Many have fallen into the trap of being overly enthusiastic about new technologies. Newer technologies often offer improvements but lack the experience and stability needed for production environments.

Here are some examples of overzealous adoption:

  1. Building an E-commerce System: Using unfamiliar technologies like NodeJS, Micro-services, and modern patterns (CQRS, Event Sourcing) for a grand e-commerce system, leading to operational challenges and eventual rollback to simpler methods.

  2. Micro-frontend Failures: Trying micro-frontends based on a few articles, resulting in fragmented and inconsistent user interfaces, and extended development times.

  3. Obscure Databases: Choosing a key-value database nobody has experience with, complicating simple tasks and causing operational headaches due to a lack of backup, debugging, and tracing experience.

  4. Unfamiliar Programming Languages: Introducing a brand-new programming language to the team and the world for simple problems, leading to numerous errors and time wastage.

Ignoring Suitability in Software Architect

Suitability is crucial when deciding whether to apply a solution to a problem. Ignoring this can be a hallmark of a poor SA.

Questions to answer about data:

  • What is the data structure?

  • How much data is there?

  • What is the read/write ratio?

  • What are the read/write characteristics?

Here are some humorous yet common design mistakes:

  1. Distributed Systems: Implementing distributed databases and systems for simple management tasks, turning the system into a black box difficult to debug directly.

  2. Ineffective Partitioning: Partitioning data on a single node with evenly distributed data, causing hardware burdens and inefficiencies.

  3. Schema Evolution with SQL: Using pure SQL for continuously evolving database schemas, leading to downtime and inefficiencies, even when NoSQL might be more suitable.

Excessive Variety in Software Architect

A bad SA loves 'hotpot' – mixing too many technologies and solutions into one project.

The hotpot approach results in:

  1. No Sharing: Different languages and technologies hinder experience sharing among developers.

  2. No Replacement: Difficulty in replacing team members proficient in unique technologies.

  3. No Inheritance: Each new service starts afresh, lacking shared experience.

DevOps teams suffer the most, managing the complexity of multiple technologies, lacking both development and operational expertise.

By avoiding these traps, one can build more robust, maintainable, and efficient systems.

Comments

bottom of page