The decades pass, but we still write software in the same way as in the XX century.

Our software is a large castle, formed by several layers superimposed and mixed, in order to facilitate its own maintenance, but which, in fact, end up creating the opposite effect: a true monolith.

Whaaaattt?

Oh yes! Class structures, complex domain hierarchies and extrinsic aspects incorporated into the code make it expensive, and difficult to maintain and operate.

In this article, I want to focus only on the “extrinsic aspects” of the source code, that is, those things that shouldn’t be “embedded” within the source code.

According to Oxford Dictionary:

ex·trin·sic: not part of the essential nature of someone or something; coming or operating from outside.

Extrinsic factors might affect time budgets

There was a time when we started to identify these “extrinsic aspects” as just “aspects”, especially in the Java world, where Aspect-Oriented Programming techniques emerged.

“In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. It does so by adding additional behavior to existing code (an advice) without modifying the code itself, instead separately specifying which code is modified via a “pointcut” specification, such as “log all function calls when the function’s name begins with ‘set'”. This allows behaviors that are not central to the business logic (such as logging) to be added to a program without cluttering the code core to the functionality. AOP forms a basis for aspect-oriented software development.”

Although well-intentioned, this practice only “masked” the “extrinsic aspects”, keeping them inside the source code in some way, and helping to increase the complexity of maintaining the software. While there are those who disagree with this statement, this is easily proven when trying to maintain AOP-based software from 10 years ago.

What are we talking about? Give me examples!

Of course! Here are some examples of extrinsic aspects that are easier to identify: Security, scalability, high availability. However, there are others more “exotic” such as: Discovery and control of services.

Exemplifying the issue of high availability and scalability, we have the insistent use of multithreaded programming as a mechanism to parallelize processing.

And we can cite several examples of “extrinsic aspects” incorporated in the software, as in this list:

• Internally controlled elasticity: When a program decides to increase or decrease the consumption of resources by scaling a number of threads or processes internally.
• Remote service control: When a program stores a list of names or addresses of other servers, using it for load balancing or task distribution.
• Internal workflow control: When a program controls stages of complex processing using its own internal structures.

Many bad ideas arise from good intentions

Programmers often like to solve problems themselves, without relying on other people and other tools, bringing responsibility for things they shouldn’t have into the source code.

This type of attitude is seen as “proactivity” or “agility”, a characteristic often appreciated by short-term vision managers.

Why is this a bad thing?

I can name a few simple reasons, but there is a very clear reason: Your software must become cloud-based, and these “extrinsic aspects” make it difficult or impossible to make the best use of this technology.

Cloud-based software does not necessarily need to be hosted by a cloud service provider, such as AWS or Google Cloud.

Techniques such as: Virtualization, Infrastructure as Code, Immutable Servers, Service Discovery, Service Choreography, and many others are becoming the standard in progressive and modern companies, and in order to be successful in their use, it is necessary that your code be the most simple and functional as possible, ie: Flat.

I say simple, capisci?

Today there are tools to assist interconnection and scalability such as: Kubernetes, RabbitMQ, and Apache Zookeeper. You should let tools like these take care of the “extrinsic aspects” of your software, focusing only on the functional aspect of every program you create.

Every time you think about adding new threads to your program, you are embedding things in it that should be external, increasing its complexity and maintenance cost. Even if it seems like a good idea, think about the operation and the complexity of what you are doing now.

Letting “extrinsic aspects” be externally managed gives Devops greater freedom to provide your solution more efficiently, lowering costs and increasing the economic and operational efficiency of the software.

This article is republished from hackernoon.com