Essential decisions in modern software development

Software development is long-lasting and strategic.

Nearly all discussions I followed on LinkedIn or Medium are?without context. You must consider the company's circumstances and environment while making such an important decision. So instead, you will get some half-backed comments on LinkedIn where technical persons mention best practices or quote Martin Fowler's "Monolith-First" without much explanation or background.?

There are many problems with such discussion, but the biggest problem for readers, who are forced to make good decisions for the years to come, is the notion that you should blindly go with the modular Monolith because you can always change later. Excellent flexibility, right??Wrong.

On a timeline of 3-5 years, you will run into dire problems for your company. The software will change, requirements will change, and clients will change. The world has never changed as fast as it is these days.?Therefore, you must stay flexible, act, and react to any problem in the near and far future.

It's not technically impossible to migrate away from a monolith. But, again, Martin Fowler describes one pattern as the "Strangler Fig Pattern," which is a viable way I used myself successfully.?The question is not if it's technically possible but if it's likely doable and wise from a business standpoint.

Here comes the wrong part.

The amount of time and money necessary to migrate an application as green- or brownfield development is enormous and can overtax an SMB quickly.?Why is that?

Applications in the SMB area are mainly created as core products or for Digital Transformation. In both cases, the developed?solution is of mission-critical importance for the company. This likely means that your development teams are already 100% loaded with work to keep the existing legacy solution alive and in place.?Your company is aligned with the current solution and is not yet prepared for an upcoming migration.

That means you need to extend in terms of employees or contractors if you want to migrate somewhere. To migrate into a new form of technology means you need to hire professionals who are already familiar with a more complicated technique than yours is now.?Yes, this is costly and NOT quickly done in daily business, as it seems in most questionable discussions on the internet.

The other negative aspect is that migration will take around the same amount of work as the initial development stage. Yes, the?same amount or even more, depending on context and circumstances. You won't reuse things; you build them again!?In this case, it doesn't matter if it is green- or brownfield.

Think about this approach twice, but only after you have read the following part.

Understand what Microservices are standing for on a strategic level

The idea of?decoupling and separating?is old, as we can see if we look into the?Service-Orientated-Architecture. However, in the last years,?Microservices have been hyped, and these days it's the?composable architecture?that people are talking about. So why have they become popular?

Especially Microservices are often advocated because you can scale them quickly. But this is only one aspect and is?not the most important in the SMB sector.

In reality, it's about staying flexible and avoiding a?Legacy-Deadend after three to five years. Being able to separate is vital for this long-term goal. Microservices were just the first step towards modern approaches to staying on top of your game, even as a small company with a limited budget. Other current methods follow a similar idea, like cloud functions in a JAM-Stack.

The idea of decoupling and separation is to stabilize your process long-term. Microservices are just one tool for this. The Monolith, no matter how modular, isn't by definition. Here I refer to my experience, not some context-free posts, discussions, podcasts, or articles.

Continuous enhancement and the ability to substitute parts of your solution quickly

Why do solutions suddenly become legacy or even obsolete? Are 100% of their parts broken or not adequate anymore? No, probably not. Most of the time,?some features need to be changed, but they are heavily interweaved in your application. Simply put, you can only remove this specific part with a heavy impact on your application.?As a result, you lack the flexibility to act and react. The more time goes by, the worse it becomes.

Some call it migration; I call it rebuilding

In such a situation, you must go back to start and repeat a process you already have done.?Some call it migration; I call it rebuilding. Is this worth it? Answer this question for yourself.

A solution is to accept the overhead for microservices or similar approaches. However, it is less of an overhead compared to the hidden afford in the future you create at this very moment.

Think about the advantage of substituting specific parts of your application or business context with new features without affecting the rest of your application. This capability is essential for your company's long-term success and stability?when the software we are talking about is mission-critical.

In Germany, there's a saying: "I am poor; I cannot afford cheap."?

This saying refers to buying and building quality products that last long. For example, I remember the Miele washing machine, which my grandmother had for 35 years after she needed to change a water pipe to keep using this machine. Yes, this washer was expensive when my grandparents bought it. But would it be less costly to buy 2-3 less expensive devices and repair them more often over this period? I think you know the answer.

If a developer or consultant makes this kind of decision, they tend to look into the short-term benefits; they want to help you make it easy, which is okay. So start easy, start cheap, and you can always fix it later. But in reality, it is expensive to start over and over again. Or, in my grandmother's example, buy a new washing machine over and over again.

Everyone should continuously learn to understand other people and different ways to achieve things

I refer to developers and consultants here. Take this as food for thought, and remember that your words influence many people. The tech world is still tiny in some aspects. Everyone should continuously learn to understand other people and different ways to achieve things.

Conclusion

Monoliths aren't something wrong; they worked for decades and brought us all to the point where we are today. They are easier to use, but you will likely fall into a trap long-term. No matter how disciplined you are.

Goals like business stability are a priority over avoiding technical afford on day one.

Please think carefully about how you want to structure your solution, and keep in mind that it's a business decision, not primarily a technical one.?Goals like business stability are a priority over avoiding technical afford on day one.

Invest in the foundation that will work for you for more than five years. Don't imagine your company so wealthy that it can afford all the necessary resources to migrate to something adequate for the long-term goal. I think the chance is high that you will struggle to shoulder this effort.

If you conclude you need to start with a Monolith; I am totally fine with that decision.?However, I wanted to make you think about this topic with more context?and let you know about my concerns and why I prefer the decoupled way of work. I simply dislike the low-depth mentality of conversations I read on LinkedIn and Medium daily. CTOs and Tech Leads should not make decisions because people say something; Every decision must be made specifically for your circumstances in your business by you.?

It's you who is responsible in the long run. It's not the developer or the consultant, or some influential Thought-Leaders.?

--

Have a merry Christmas ??, and thank you for reading this article ??

I am looking forward to 2023 and many more great conversations on LinkedIn.