DEV Community: Pooyan Razian

Cloud vendor lock-in! How much should I be scared of? 😱

Pooyan Razian — Wed, 07 May 2025 04:00:41 +0000

What is vendor lock-in?

Vendor lock-in refers to a situation where an organization becomes overly dependent on a specific vendor's products or services, making switching to alternatives costly, time-consuming, or technically difficult. Over the years, many companies have experienced frustration when trying to move away from large vendors like IBM, Microsoft, or Oracle due to contractual constraints, proprietary technologies, and sudden pricing changes. A recent example is VMware's acquisition by Broadcom, followed by significant pricing changes that disrupted many businesses.

Some examples?

In startup environments, it's common to hear voices urging multi-cloud strategies or insisting on only using "cloud-agnostic" tools to avoid a potential lock-in that might never materialize. Some even advocate picking tools that must remain relevant for the next 10–20 years—a nearly impossible task. 🙃

Here are some example you too might have heard:

Self-managed Kubernetes

Some teams insist on managing their own Kubernetes clusters because:

"Big companies use Kubernetes", so we should too.
It's open-source.
We should be cloud-agnostic and avoid vendor lock-in at all costs.
Se-managed appears to be cheaper than using a managed alternative.

While these reasons seem valid on the surface, managing Kubernetes introduces significant operational complexity. Cloud providers offer fully managed services like Amazon EKS, Google GKE, Azure AKS, or even serverless options like AWS Fargate, which significantly reduce this burden. But still, some prefer self-hosting just to avoid a perceived lock-in. 🫠

Let's build our "own" datacenter!

Although less common today, some businesses still believe running on-premises is more cost-effective and provides more control. Reasons typically include:

Public cloud is too expensive compared to owning hardware.
1. "Once you're in the cloud, you're stuck."
2. Physically owning the infrastructure seems safer.
3. Fear of cloud providers "stealing" their ideas. 😂

Recently, influencers like David Heinemeier promote the idea of "let's build our own datacenters" by focusing only on hardware costs. But building and maintaining a datacenter requires considering total cost of ownership (TCO), which includes staffing, the knowledge that is not common anymore, upgrades, security, including physical security, availability, and much more.

We should only use open-source!

Open-source software has been a major driver of innovation and collaboration. It enables transparency, reusability, and often better security insights. However, an overcommitment to open-source can sometimes prevent teams from using excellent managed solutions just because they're proprietary. I'm a big fan of OSS, so don't get me wrong. For example, preferring PostgreSQL or MySQL over managed solutions like Amazon RDS or Google Cloud SQL might lead to higher operational overhead, especially for teams without strong DevOps support.

Why this approach is dangerous?

Making strategic tech decisions based solely on the fear of vendor lock-in often leads to unnecessary complexity. Imagine building software without any libraries or frameworks because they're "opinionated." That logic, if taken to the extreme, leads to teams reinventing the wheel while convincing themselves their startup is building something truly unique. Some leaders boast about being "cloud-portable" and ready to switch providers overnight. In theory, that sounds great. In practice, it's a costly abstraction.

All decisions in engineering are trade-offs:

Should you master multiple programming languages to be vendor-agnostic or pick one that fits your use case well?
Is it practical to use a universal ORM for every database engine or choose one tailored to your stack?
Does it make sense to pay cloud providers for managing repetitive operational tasks?
Is simplicity more valuable than the power of customization and flexibility?
Do you really need every advanced feature of a tool or only a reliable subset?
Is it wise to invest team time in debugging and maintaining infrastructure?

Vendor lock-in only in choosing the public cloud provider?

Vendor lock-in isn't limited to cloud providers. The moment you select a programming language, framework, database, or third-party service, you are accepting a level of dependency. The more deeply you integrate a technology, the harder it becomes to replace.

You may find yourself locked into:

– A specific programming language.

– A database with custom schemas and stored procedures. (DB? logic? Hmm...)

– Custom internal platforms built by someone who left last year. OOPS! We have no documentation either.

– Third-party services for billing, auth, or analytics.

Cloud providers are just one among many dependencies. The key is to choose wisely and be deliberate—not paralyzed by hypothetical future migrations.

What should I do then?

Aim for pragmatic simplicity. Embrace managed services where they make sense, and minimize complexity where possible. The real danger isn’t vendor lock-in—it's complexity lock-in.

Combining too many tools or customizing every layer of your stack increases system entropy. Over time, the culture of "don’t touch it, it works" takes hold. Eventually, systems become so convoluted that nobody understands them—let alone migrates them.

Stay flexible, stay curious—but don’t fear lock-in so much that you lock yourself into choosing over-engineering complexity (when it is not needed yet) or indecision.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

DevOps is a culture, not a role!

Pooyan Razian — Tue, 08 Apr 2025 04:00:40 +0000

DevOps is not a “role”

DevOps was introduced:

to change the culture (which also needed a change in traditional management thinking and habits)
to empower teams to continuously grow with more autonomy and less dependencies (which needs more trust, governance, and better risk management)
to continuously experiment, analyze the risk, learn, and adapt to changes

It was an attempt to change management style, but... Instead, again, we got "isolated DevOps/Ops" teams and tens of thousands of meetings under different names.

Remember...

DevOps != an isolated separate team of DevOps engineers (ops simply renamed to DevOps) + Scrum/SAFe

DevOps != CI/CD pipeline

DevOps is...

DevOps is a culture and a mindset

DevOps is a way of working

DevOps is a way of thinking

DevOps is a way of continuous improvement

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

You don't need that many meetings

Pooyan Razian — Mon, 07 Apr 2025 04:00:40 +0000

⏳ Daily Standup (report to me style or daily Scrum to align?) 😵‍💫

⏳ Project Status Update (Weekly Sync) 😵‍💫

⏳ On-Call Rotation / Incident Handover 😵‍💫

⏳ Quarterly Business Review (QBR) 😵‍💫

⏳ Backlog Refinement (Grooming) 😵‍💫

⏳ Incident Review (Postmortem) 😵‍💫

⏳ Product Roadmap Meeting(s) 😵‍💫

⏳ Change Management / CAB 😵‍💫

⏳ Code Review / Peer Review 😵‍💫

⏳ Inter-Team Alignment(s) 😵‍💫

⏳ Infrastructure Review 😵‍💫

⏳ Prioritization Meeting 😵‍💫

⏳ Cross-Team Sync(s) 😵‍💫

⏳ Sprint Retrospective 😵‍💫

⏳ Architecture Review 😵‍💫

⏳ User Story Mapping 😵‍💫

⏳ Security Review 😵‍💫

⏳ Kickoff Meeting 😵‍💫

⏳ Team Check-in 😵‍💫

⏳ Sprint Planning 😵‍💫

⏳ Design Review 😵‍💫

⏳ Demo meeting 😵‍💫

⏳ Sprint Review 😵‍💫

⏳ DevOps Sync 😵‍💫

⏳ One-on-One 😵‍💫

⏳ Bug Triage 😵‍💫

⏳ Tech Sync 😵‍💫

⏳ Dev Sync 😵‍💫

.

.

.

But, in most cases we can just replace a 2 hours meeting with an email, a Slack message, or a simple comment on a ticket. Then, instead of having isolated communication islands, where people have to "figure out" who has made decision together with who, you will have fewer sources of truth, were everyone can just go an check themselves. This way, you will have more time to communicate the most important messages that really need a synchronous way of communication, and you will have more time to focus on your work. If someone later joins the team, in most cases they can just check the git/PR/ticket history and understand. This way, also, you will have more time for team building and socializing, which is also important for a healthy team culture.

So next time...

Ask yourself:

Do we need them all?
All the time?
Do we always need a synchronous way of communication? Or asynchronous is enough?
Can it be replaced with a simple comment on a ticket?
Or, as an exception, should I also communicate this specific message synchronously in a meeting/call?

Also, remember, now that you are replacing your direct communication with a more efficient async one, you should always set aside time for fun/chat/team building, otherwise the team spirit will be gone.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Who really is a senior senior developer?

Pooyan Razian — Sun, 06 Apr 2025 04:00:40 +0000

Do we type faster?

Do we write error-free code all the time?

Have we memorized all syntaxes and algorithms?

Do we know everything?

Probably not!

That's a 10x dev job!

The myth of "years of blah blah" seniority in IT

The idea that seniority is only about the number of years in the field is misleading. Just because someone has been coding for a decade doesn’t mean they have been growing, learning, or adapting to new technologies.

Experience is valuable, but only if it is accompanied by continuous improvement, problem-solving skills, and the ability to make sound technical decisions. There are people who have been doing the same thing for decades without even considering to learn something new. Such people are not only not senior, but also will bring a toxic culture and a heavy inertia to your team.

Seniority isn’t just about technical skills—it’s also about leadership, communication, and understanding business needs. A great senior developer knows when to push back on unnecessary features, when to mentor junior engineers, and when to advocate for refactoring versus shipping quickly.

Value people who value learning, growth, and adaptability; and forget about measuring based on stupid things like "years of experience".

Time to ask yourself ...

Do we measure based on ...

Lines of code?

Number of commits?

Number of Pull Requests?

Number of fixed bugs?

Number of features?

If your answer is yes, then you'd probably hire based on "years of experience".

If you are looking for something to "show progress", such things can easily be tempting to be valued. KPIs will be met. Something can be presented as "progress". High-level managers will be fooled, and mid-level managers will be happy! If that's the case, "seniority" can also be measured by "years of experience" and metrics like that.

But real seniority is ...

But real seniority is about impact, decision-making, and mentorship. It’s about knowing when less code is better, when not to reinvent the wheel, and how to guide a team towards better software, not just more software.

Instead of focusing on vanity metrics, ask deeper questions: Who is enabling the team to succeed? Who is reducing technical debt? Who is improving developer experience? These are the real signs of seniority.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

The reality of story points

Pooyan Razian — Sat, 05 Apr 2025 04:00:41 +0000

What is 1 story point?

I bet if you ask 10 people, you'll get 10 different answers.

Yet, we "estimate" and measure based on that.

What is the origin of story points?

Story points originated from Extreme Programming (XP) as a way to estimate effort without tying it directly to time. The idea was to move away from inaccurate time-based estimates and instead use a relative sizing approach.

They were inspired by techniques like Wideband Delphi (derived fromDelphi method as a forecasting tool) and Planning Poker, where teams collectively assign values based on the estimated complexity, known risks, and guesstimated effort.

What problem did it want to solve?

Traditional time-based estimation often led to missed deadlines and unrealistic commitments. Story points aimed to solve this by:

Encouraging relative estimation over absolute time-based guesses.
Reducing pressure on developers to commit to unrealistic timelines.
Allowing teams to adjust based on historical velocity rather than gut feeling.

What are the common alternatives?

While story points are widely used, some teams prefer:

Time-based estimation: Estimating directly in hours or days.
No estimates: Delivering work in small, consistent chunks and tracking throughput instead.
T-shirt sizing: Categorizing work into Small, Medium, Large, and XL sizes.

Why none work?

Every estimation method has flaws:

Time-based estimation: It is almost impossible to predict everything in creative domains where things change quite fast.
No estimates: It works well for mature teams but can be hard to adopt in traditional orgs.
T-shirt sizing: It’s still a form of estimation but lacks granularity.

Ultimately, estimation is always imperfect because software development involves uncertainty and variability.

When things cannot be estimated properly, how can developers commit to what they promise as when they are "estimated"? If estimation is not important and failing them is okay, they why do we need to pressure? Is it okay to train our team to estimate to fail? Will that become a part of the culture?

If it is not okay to fail, then, these estimates will be used as a tool to pressure and point at the most important assets of modern companies when timelines are not met.

What to do instead?

Instead of obsessing over story points or alternative estimation methods, teams should focus on:

Delivering work in small, manageable increments.
Tracking actual throughput over time.
Communicating openly about uncertainties and risks.
Using historical data to have an idea about the future and be open to continuously keep their plans updated.
Removing the "update to me" management style, and build teams based on trust.

The goal isn't perfect estimation—it's delivering value consistently and somehow predictably.

Remember, quantifying uncertainty doesn't eliminate it. It just gives the illusion of control. The main values rely on things that are qualitative, and cannot be easily measured.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Scrum is a nice term to hide bad management

Pooyan Razian — Thu, 27 Mar 2025 04:00:40 +0000

Once a wise man said: Fire all Scrum Masters and your non-technical managers who run your IT departments, and watch your productivity to boost up! In most cases, all you need is to hire highly-experienced Tech Leads and show trust in them. Communicate with them and share your insights, answer their questions, and provide them with what they need, including but not limited to the budget, time, ad-hoc specialist consultants, and coaches who would work for them to improve their non-technical skills. The rest, they will figure out themselves.

Why traditional management didn't fit IT?

Traditional management was designed for industries where work is predictable and repeatable and structured in a way that allows managers to oversee and control output through rigid processes. However, IT projects, especially software development, are highly unpredictable and creative and require continuous learning and adaptation. Traditional management's command-and-control style slows decision-making, discourages innovation, and often results in micromanagement instead of trust-based leadership.

What problems Scrum wanted to solve?

Scrum was introduced to address the inefficiencies of waterfall-style project management, where long planning phases often led to outdated requirements, a lack of flexibility, and frustrated developers. It aimed to bring more collaboration, iterative delivery, and adaptability to changing business needs. The core idea was to empower teams, break down silos, and reduce bureaucracy while focusing on delivering working software frequently with customer feedback.

Agile Manifesto vs. Scrum

Many assume that Scrum and the Agile Manifesto are the same, but they serve different purposes. The Agile Manifesto is a set of guiding values and principles designed to foster flexibility, collaboration, and responsiveness in software development. Scrum, on the other hand, is a framework that attempts to implement Agile principles through structured roles, events, and artifacts.

While Scrum tried to align with Agile in theory, its real-world implementation often contradicts the core values of the Agile Manifesto. Instead of prioritizing individuals and interactions over processes and tools, many Scrum implementations become rigid and bureaucratic, focusing on enforcing rules rather than enabling teams. This raises the question: if Agile promotes adaptability and self-organization, why has Scrum become so prescriptive in practice?

What is Extreme Programming (XP)?

Extreme Programming (XP) is an Agile software development methodology that emphasizes technical excellence, continuous feedback, and teamwork. It introduced practices like pair programming, test-driven development (TDD), continuous integration, and frequent releases to ensure high-quality software. While Scrum focuses more on process and roles, XP focuses on engineering practices that enable rapid iteration and code quality. Many Scrum teams unknowingly borrow XP practices but fail to implement them properly.

Traditional management with a nice shiny name?

Unfortunately, in many organizations, Scrum has become nothing more than traditional project management disguised under new terminology. Instead of empowering teams, many Scrum Masters and managers use daily standups as micromanagement tools, Sprint planning as a tool to push developers with tight, unreasonable deadlines without asking the "why" questions and clarifying the main goals to achieve, and velocity metrics as a means to pressure developers. The original goal of self-organizing teams has been lost, replaced by rigid processes that feel just like old-school management but with new buzzwords and many different meetings with slim to no outcome!

Final words

What is often practiced under the name of Scrum is, in many cases, a flawed combination of poorly adapted XP practices and outdated management habits. Instead of fostering trust and autonomy among software developers, many organizations have turned Scrum into a rigid system that prioritizes tracking metrics over meaningful progress. The original intent of Agile—to encourage adaptability, collaboration, and self-organization—gets lost when processes become more about control than empowerment.

Take daily standups as an example. They were meant to help teams align and plan their day efficiently. Yet, in many environments, they have become status-reporting sessions where managers scrutinize progress and pressure individuals to be "faster." This misunderstanding of Agile leads to an obsession with speed rather than sustainable development. Agile is not about rushing work through arbitrary deadlines or excessive meetings; it is about creating an environment where teams can adapt, innovate, and deliver real value.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Europe is copying China and Iran's IT strategy

Pooyan Razian — Sun, 23 Mar 2025 04:00:41 +0000

It's interesting to see the panic. Now it's time for Europe to copy China's and Iran's IT strategies! 😆

Our IT is fully dependent on the US. If the US shows us the middle finger, we are doomed! 😱

Oh, we should do something about it! 😱

First step: GDPR. Let's move our data to Europe! 😱

Let's fine American companies! 😏

Now: Let's use European cloud providers! 💪 We are the bezzzzzt!

But, wait! What European cloud provider? 😱

You mean, the one that was founded by someone who is more into music than IT?

The one that recently had a big fire in one of their Datacenters in Strasbourg?

The fire that interrupted nearly one week operations of many thousands of websites?

The one that provides a French-level "support"? 😉 We all know what that means.

You don't speak French? uh, sorry we can't support you. 🙃

You speak French? Good, but, still, give us tiiiiime to figure out. 😅

Or you mean Lidl Cloud? While Germany cannot even compete in the automotive industry anymore...

🙋 Okay, but why did Iran and China do that?

Because the US has proved many times that it cannot be trusted. For example, when Iran signed the JCPOA agreement with the US during the Obama administration, later, Trump teared it up! And even sanctioned the person who negotiated this peace agreement, Mr. Javad Zarif, whom many agree deserved a Nobel Peace Prize! (you can read more about it in another article that I wrote earlier) How crazy is that: sanctioning the person who negotiated one of the most significant peace deals in the world!

The real face of "freedom of speech" was uncovered

Meanwhile, recently, the US and the UK uncovered their real face of "freedom of speech" by criminalizing the ones who support Semits of Palestine and stood against Izrael, as the "project Izrael" was founded based on anti-semitism = anti-Palestinians = anti-Arabs and the hat3-based Naz1 anti-specific-religion mindset (Ashk-e Nazi ZiØn1sts) to ethnically remove Palestinians from existence, and then help the US expand in the continent of Asia by invading Palestine, Lebonan, Syria, Iraq, Iran, Russia, China, Japan, etc. So then they could colonize the whole continent of Asia, similar to what the West brought to Africa, and then began to steal their history, land, and resources. Still wondering why German Foreign Minister Annalena Baerbock happily met with Joulani, a former 1$1S leader?! Who helped the US and Izrael to create such extr3mist groups? Why? To rebrand Asia as "Evil/bad" and then justify their inhumane actions in the continent of Asia. Starting from the Western parts of it, which you named "the Middle East" in the Western "divide and conquer" fashion/mindset. Who created all these immigration issues that no one is happy about? Who caused it in the first place? Who voted for such politicians? Time to think a bit... 🧠

You can read more about Ashk-e Nazi ZiØn1sts (rebranded to ✡️) in the part 3 of another article that I wrote earlier. Also, you can read more about why they are anti-semitic.

Alternatively, in this article read about one of example extremist t3rrorist group that your politicians support, similar to the ones they created in Afghanistan and Syria and supported them to kill innocent civilians! Have you voted for them? Then, your hands are dirty with the blood of people who were butchered in all those West-Asian countries by your proxies and all those extremist groups that your politicians created! Are you unhappy of immigrants? Are you unhappy of economic issues? Do you think China is evil? Do you hate others based on their religion or ethnicity? If yes, you should think a bit more and remove all the propaganda that you were fed by the media and politicians. If you think a bit, you might understand the affects of what you have done.

If you want a change, you should start from yourself. With the existing hate-based supremacist mindset and the lack of diversity and open-mindedness, nothing will be changed; and as already planned by your ex-allies, Europe will be the next. Remember, Brexit didn't happen for no reason. 😉

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

A bad advice by juniors who think they are seniors

Pooyan Razian — Sun, 09 Mar 2025 04:00:40 +0000

It's interesting to see some still give the same kinda advice! ⚠️

I remember, back then, some were thinking that if you could write code in Vi/Vim, you could be considered a "hacker"! 😂 Or if you were a Windows guy, you were encouraged to memorize syntax and everything and write code in simple text editors like Nodepad++! 😃

Those who were in the market for a few years were advising the new ones not to use IDEs "because they make you lazy". 🤦 We were told that "real programmers" don't use IDEs! 😂 It was pretty common to see companies asking their candidates to write code on a piece of paper or a whiteboard! 🤦 You were asked about syntax! Things like "typing speed" were the most important thing to brag about! Like we were expected to be typists! 😃

Twenty years passed, and still, people give similar kinda advice!

Remember ...

Memorizing things might make you an average mid-level manager or a call center staff but not a programmer who needs to be creative.

✅ Use the tools efficiently.
✅ Learn from all sources, even your AI, as your CodeReview assistant/advisor!
✅ Use your brain to think and be creative instead of memorizing things.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

IT job market is dead! Here is why

Pooyan Razian — Sat, 08 Mar 2025 10:15:09 +0000

5-10 years ago, software developers were considered gods! 🌟

Corona 🦠 hit, and everyone who had the chance, opened a company and became a highly paid consultant. 💸 💸 💸

... and we ended up having a lot of juniors in this field who were just good at presenting themselves. Being hired by onion layers of managers/connections who had no idea what values to look for. (we call that corruption in Iran, but interestingly, it is called "connection" in the West!)

Later, a new round of financial crisis began...

... thanks to all the stupid wars that the US and the international Mafia of Zionist bankers, who founded their rebranded hate-based "Project Israel", took the West into.

... and many businesses decided to lay off. But who should be laid off? Top managers? No. Mid-level managers? No. That's why we ended up seeing interesting cases all over the place where even sometimes 5+ Scrum Masters & 5+ Product Owners and Project Managers & 5+ more onion-like other types of managers (with different names) all managing 1-2 Software Developers!!! 🤦 (yes, I've seen that! More than once!)

And of course, those tech staff mostly were chosen from fresh graduates and juniors.
The "cheapest option"... For what matters the most!

... and then, by the end of the day, when none of those imaginary deadlines were met, who was to blame?

Of course, those poor developers!

So, what was the cure? 🤔

Of course, you had to hire more managers, more Scrum Masters, more Project Managers, more meetings, more status updates, more Excel sheets, more Word documents, more talk, etc. 🙃
Something to "show progress" ...
To what direction? Who cares!

Now, in 2025, the job market is officially a desert!

Thanks to those past strategic mistakes that managers were happily making.

But, why didn't we have any problems before?

Because the international banking system was pumping fake money/funds into selective countries that were marked as "friends of the US and friends of Israel" while the civilians of countries like Iran were collectively punished for not being enslaved well enough under this "supremacist" system.

The luxury that, for example, China didn't have. That's why they had to build a highly resilient efficient system from ground up, unlike all these inefficient systems we see in Europe, which are built around "connections" earning money together. The almost unlimited amount of money/funds/credits that has been pumped by Western governments and this new corrupt neo-fa$$cist-supremest financial system.

Now, the situation has changed, and Europe, Nordics, Canada, etc. are not "friends" anymore...

(welcome to the club, even though you are not willing to admit it) 👋

Remember ...

2008, was a sign, you applied a patch and continued...
Brexit was a sign, you didn't get it... 😉
Corona was an accelerator that revealed some of the problems; Still didn't open your eyes.
You encouraged the War in Ukraine
You supported the hate-based genocide of Palestinians And you still support the same hate-based ideologies that destroyed Europe in WWI and WWII.

The ideology that created "Project Israel" to send "Ashk-e Nazi supremacists" to Asia, so then:

1️⃣ Europe could get rid of them. (two sides of the same supremacist cult could not live together)
2️⃣ The US and Europe could ally with them to create a new financial system, form of "enslaving banking", and control the flow of money.
3️⃣ Zionist-supremest Ashk-e Nazis could collaborate with the white supremacist Europeans/Americans/Brits to run genocides for them and colonize Asia. Starting from the Western parts of it. (what you call the Middle East in the Western "divide and conquer" culture)

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Automatically delete old GitHub Actions runs

Pooyan Razian — Sun, 02 Mar 2025 09:08:36 +0000

In this article we will learn an efficient way to delete old GitHub Actions runs.

GitHub Actions is a great tool for automating your workflow. However, if you have not set a retention policy for your runs, you may end up with a lot of old runs that you do not need anymore. In this article, I will show you how to delete old GitHub Action runs.

GitHub Actions runs are the executions of your workflows. They can be triggered by pushing a commit or creating a pull request, or on a schedule, etc. based on how you have defined it in your workflow config files. Those config files act as a recipe or a blueprint and each run is an instance of that recipe. (similar to class vs object if you are a programmer) Each time a workflow is triggered, a new run is created, and you can see the list of runs in the Actions tab of your repository.

How to delete old GitHub Actions runs

One way to delete old logs and artifacts is to globally set a retention policy for all repositories in your organization. This can be done by going to the organization settings and set this: The problem with this approach is that you cannot granularly set the retention policy for each repository. Also, it needs to be done by an org-level admin. So, if you do not have the access to set this policy for your org, or you want to set a different retention you should either manually do it, by opening the Actions tab of your repository and deleting them all manually one by one, which can be time-consuming, or you should build your own solution to call the GitHub API to list and delete them automatically. This is not a one-time job, so you end up having to do this again and again.

To save you time, I have created a public Action, available on the GitHub Marketplace that you can use for deleting old Actions runs. It can be found: here.

Right now, in this initial version, it accepts the following inputs:

token: The GitHub token to use for authentication. (required)
days-ago: The number of days ago to delete the runs. (required)
dry-run: If set to true, the Action will only list the runs to be deleted without actually deleting them. (optional, default: false)
keep-latest: The number of latest runs to keep. (optional, default: 0)

For the token, you can just use the {{ secrets.GITHUB_TOKEN }} which is a default secret that GitHub provides to each run. You can read more about it here.

You can use the dry-run option to test the accuracy of the Action before trusting it to delete your runs. And you can use the keep-latest option to keep the latest runs, even if they are older than the days-ago value. This can be useful if you want to keep the latest runs for a specific reason.

Here is an example workflow that uses the Action to delete runs older than 30 days:

on:
  schedule:
    - cron: '0 0 * * *'  # Specify your own schedule

jobs:
  delete-old-actions:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4 
      - uses: yanovation/delete-old-actions@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          days-ago: 30

And when it runs, you will see the list of deleted runs in the job log:

The only cons of this approach that I can imagine is that it consumes additional minutes from your limits, but that is not a big deal in almost all cases. To minimize this, you can even schedule this workflow to run once a month or so, but bear in mind that this will make the deletion dates less accurate.

Do you already use this Action?

Do you know any other solutions?

Do you have any suggestions?

Let me know.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

From "spaghetti code" to "spaghetti architecture" 🍝

Pooyan Razian — Sat, 01 Mar 2025 04:00:40 +0000

From "spaghetti code" to "spaghetti architecture" 🍝

"Serverless" with some 100x delicious dependencies in different layers 😋

Note: All the names and events in this story are fictional, and any resemblance to real people or events is purely coincidental. The story is completely made-up but is inspired by a mix of a few common patterns I have either seen myself or heard from others in the past few years. The purpose of this story is to share a common trending scenario and a few mistakes that can cause IT-based startups to fail.

Spoiler alert: This article might refer to some 100x delicious dependencies in different layers. 😋

OK, here the story begins ✨

Seven years ago, during the IT hype, Mark took a few courses to learn web development using HTML, CSS, JavaScript, PHP, and MySQL. Then he was hired by a startup as a web developer. His main task was building the application's frontend using jQuery and later with React. Gradually, he also learned how to build backend APIs using Node.js and Express. He was the company's full-stack developer at this point. 🥳

Back then, they had one extensive "old" application that no one dared to touch and a new one built with a cleaner approach. The old code had files containing thousands of lines of code. A mix of backend logic, database queries, jQuery, HTML, and CSS. A small fix or a single change in one part of the code could break 10 more things! 🍝 He could easily see how difficult it was to maintain and extend the old application, and he always wanted to avoid making the same mistakes as the previous developers had made. It is always "others" that make mistakes, right? 😉 He studied and practiced design patterns to write cleaner code.

A few years later, he was approached by a recruiter on LinkedIn for a CTO position in a retailer startup. He was living in a small country and knew that companies are desperate to find technical staff in that region, but he was not expecting to be offered a CTO position. He was unsure if he was ready for that, but after a few interviews, he was hired for the position. He was surprised and excited at the same time! The company was in its initial stage and did not have enough money to hire more developers, so he had to do everything by himself.

He knew that he had to learn a lot to build the product. Mark had a friend named Alex, a technical manager at another startup. He asked him for advice. Alex told him that in their company, they were using TypeScript for frontend, backend, and even for writing their Infrastructure as Code (IaC). To Mark, this sounded great because then he could do everything by just learning one programming language that was not even very different from the JavaScript that he already knew! This felt like "the answer" to everything he was expected to do in this new position. 🎉 Alex also said that recently in a technical meetup, he had heard about a new thing called "serverless computing" and "serverless architecture" that could apparently simplify things. He also mentioned things like lambda functions and API Gateway that Mark had never used before.

Soon after, Mark learned TypeScript basics and tried AWS CDK (Cloud Development Kit) to build a few simple lambda functions. He was amazed by how easy it was to build and deploy a lambda function on AWS. He then learned to use API Gateway to create REST APIs and connect them together. He also learned how to start an RDS instance (MySQL) and connect it to these lambda functions using CDK. He could build his first simple CRUD application in a very short time!

Time passed, and the company grew. They hired more developers, and Mark taught them how to use these technologies. Also, one of the new seniors shared with the team how to use unit tests, and then they added a check in their pipeline to run all these tests before deploying the code. The company could not afford to hire architects, DevOps engineers, or SysAdmins because they thought a) they were too expensive and b) a small company like that doesn't need such skills.

In the beginning, everything was fine. They could build the MVP in a few years and successfully deliver it to their first 1,000 customers. Developers were happy because they could build things quickly, and the management was happy about the overall price and development speed.

After a while, now that they were using one database shared with all lambda functions, they realized even a small change in one of the services could sometimes break everything else! They were also facing some random connection issues with the database. After consulting with a few people, they decided to make these services less dependent and split the database. By then, they had hundreds of lambda functions and a couple of API Gateways, so having one RDS instance for each service was not an option. Mark spoke with his friend Alex again, and he suggested DynamoDB. Mark didn't know much about the difference between relational and NoSQL databases, or even if there are different types of such databases, but it was quite easy for him to create DynamoDB tables using CDK and use the new query syntax in his code. He mainly liked DynamoDB because he could easily create new tables without having to instantiate a database engine, define the schema, or deal with VPC, Security Groups, etc. Everything seemed very simple. To simplify things a bit more, he even used non-VPC lambda functions. At this point, they were still in the early stages and had no strict compliance requirements. At least, that's what they thought.

Even though it took a while to migrate all the data and change the queries in the code, after the migration, everyone was happy not having to deal with database-level relations of data, VPC, Security Groups, and other networking and security stuff anymore.

Meanwhile, they had hired a data scientist, Anna, to help business have a better overview. Unlike the dev team, she was mainly using Python, and she could not use AWS the way that the team was using it through CDK and TypeScript. She had to ask the dev team to create her databases and other tools that she needed. But still, she had to do everything from her laptop, because the dev team didn't want to see Python as an option and wanted everyone to use the same programming language and promote the "lovely framework" they had already built. (lambda functions, TypeScript, and their smart set of customizations to enable logging, etc.)

When the pile of poo started to smell 💩

The team was small, so they could not afford to separate the codebase for every single lambda function, so they decided to put all the code in one repository and reuse different parts of the code and libraries for convenience. They were using TypeScript, so they could easily import and reuse different parts of the code (modules) in different lambda functions.

In order to reduce the size of lambda functions, they decided to use standard Step Functions (State Machines) to split the logic into smaller parts and move some of the decision makings out of lambda functions. Soon they realized different people on the same team needed a lot of coordination and communication to make sure they are not breaking each other's code because in designing a workflow, the concept of "interface" simply doesn't exist. That means a simple change in the data structure in one layer could easily break the next ones in the chain.

After a while, they realized different parts of their system have silently become dependent on each other. At this point, they had a few lambda layers that almost every lambda function was using and CloudFormation stacks that were dependent on each other. Long-lasting state-aware Step Functions could not be easily modified or removed. Even though Mark wanted to avoid the maintenance hell of a tightly-coupled monolith that he had experienced in his previous jobs, soon, a single change in one lambda function or a lambda layer could break the whole thing!

Mark was not happy with the situation, but he didn't want to admit the mistake and find a solution for it, so he simply quit his job and went to another company. Later, the company, now a scaleup, hired a new CTO named Juliet.

At this time, the company had enough money to hire a manager who had worked for a few large companies and a few more managers to help her lead their IT. None of them had hands-on IT experience, but most had a good reputation in the industry and were quite good at people management.

The new CTO, Juliet, was a nice person but had no hands-on background in software development and was not aware of the practical and architectural challenges in this field. So she was not experienced enough to see the existing problems and was not confident enough to guide the existing team to make the strategic changes that were necessary at this point. The company continued with the same practices and habits, but the solution became increasingly slow and even exponentially complex. For each task, multiple services had to communicate with each other and wait for the response synchronously. The system was very slow, and sometimes requests were timing out. Having an overview of services and their dependencies and data flow was almost impossible. Error handling was very complex, and debugging was a nightmare... To fix errors, sometimes they were manually invoking failed lambda functions again to see if the error would be gone, but soon they realized due to not having thought about the idempotency of functions, they had ended up with some unwanted double payments or double item shipping! Fortunately, the damage was not too big, but it was still a big problem in the eyes of customers and business. At this point, it was even becoming more and more difficult to identify potential fraudulent activities from thousands of common system errors. Also, they could see some wired scenarios where a dynamically-typed language like JavaScript could cause random bugs in financial calculations that were sometimes difficult to identify or reproduce.

This led to frustration in the management and technical staff. The company started to lose its best developers. They had difficulties hiring new senior staff willing to continue building on top of this. Even though developers mostly had to work overtime, unlike the good old days, they could not meet their deadlines. Also, the quality of their product was so bad that they started to lose key customers. The business was not going well, and the owners decided to sell the company for cheap.

To save the business, the new owner had to hire an expensive team of external consultants to redesign and re-architect the solution and even build some parts of it from scratch. Juliet also left the company and soon joined another medium-sized company as a VP of engineering.

Key takeaways

It is good to remember and remind each other that:

✅ Communication over the network is slower, less reliable, and is also considered to be less secure.

✅ Serverless computing does not necessarily mean FaaS or "Lambda functions"! It is a much broader concept.

✅ Thanks to the initial misunderstanding around AWS SAM (Serverless Application Model), these days, "extensively using Lambda functions for building everything" is commonly thought to be the "serverless architecture".

✅ There are other serverless options in AWS, like AWS Fargate, that can help you use your software frameworks of choice (instead of ending up building your own framework) with more standard tooling like containers (ECS, with the least effort, or EKS, with more customization and a wider ecosystem - CNCF)

✅ In a microservice architecture, the size (of each service) matters! You might want to call them micro-service, nano-service, or whatever, but that has a huge impact on data flow, the amount of duplicated data, network traffic, service communication rates, etc.

✅ It is important to remember that you can split complexity to make it easier for different teams to work on them independently (only if you can manage to reduce dependency), but it never dies! It might even grow 10x somewhere else, so then you need to hire people to deal with that.

✅ Remember, debugging a distributed system is usually much more complex than looking at a single stack trace.

✅ Remember, achieving data consistency is a big challenge in distributed systems.

✅ Remember, things look great when you only hear about the benefits and success stories. Let's avoid marketing traps and fancy buzzwords when we are supposed to build important systems for our customers and societies.

✅ Remember, handling "distributed transactions" can be quite challenging. Using a single transactional database, you can simply roll back the whole transaction if something fails or is invalid, right? But what if you have 10+ services writing into their own databases, and then the 11th fails? What pattern should you use? Saga? Two phase commit? Compensating transaction? ... or just have an exponential retry mechanism? etc.

✅ Remember, microservice architecture was initiated to solve the problem for large companies and corporations with hundreds, not if thousands, of developers having had to work on a single giant monolith. It is not necessarily the best option for small startups with a few junior developers.

✅ Remember, microservice architecture is supposed to help you reduce the complexity by reducing the size and dependencies and moving it to another layer for someone else in your team/organization with a different set of skills to deal with, so if you still have a single shared database or a single codebase where all the services are dependent on each other, you are probably only getting the disadvantages of both worlds!

✅ Remember, hundreds of smart developers might have spent years to build secure software frameworks with a lot of tooling out of the box for you, and you are probably not going to build something better than that in a few months.

✅ In order to build a skyscraper or even a tall building, you first need to design the architecture, and then you should consult with construction engineers to verify that, and then begin by building a strong foundation. You can't start the project from the penthouse! The same applies to software.

Let's use the tools for what they are built for. Lambda and any other FaaS solutions are great for many use cases, but they are not "the answer to everything!" and are not the only serverless options.

You can leverage the power of serverless by choosing the right tools based on the use-case. Lambda, ECS (+Fargate), EKS (+Fargate), ... depending on the size of your organization, the size and complexity of your solutions, etc.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Whoever has come up with the term "Scrum master" should have seen developers as "Scrum slaves"! 🛑 ✋

Pooyan Razian — Thu, 27 Feb 2025 04:00:40 +0000

Whoever has come up with the term "Scrum master" should have seen developers as "Scrum slaves"! 🛑 ✋

Image generated by AI

The term "Scrum master" may have been coined with good intentions, envisioning a leader who guides and empowers development teams.

However, the reality for many developers often seems more akin to being "Scrum slaves." The misuse of Scrum as a mere daily report mechanism rather than a tool for effective planning and continuous learning has led to frustration and dissatisfaction among many in the developer community.

Sadly, this discontent has manifested in numerous individuals abandoning programming, changing their career paths, or transforming their roles from a technical person to a Scrum master to be on the other side.

Unfortunately, it is widespread that the misuse of Scrum has turned it into a traditional managerial tool (with a new shiny mask - Kanban, Scrum, Agile, and now Agile2! 😀 ) focused on adding meetings, pointing at developers for not delivering fast enough, and "daily reporting to management" rather than a manifest for valuing collaboration, flexibility in planning, openness to change, continuous improvement, and concentrating on what matters the most to the business/customers.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.