Forem: Emilio Acevedo

My journey from a chaotic, manual agility to a bureaucracy disguised as Scrum. And how we can get back on track.

Emilio Acevedo — Tue, 21 Oct 2025 02:04:25 +0000

In 2018, I landed in a world that called itself "agile." I had never worked with user stories or incremental deliveries, and everything was new to me. Today, after years immersed in a supposed "agile transformation," I ask myself a question that many whisper in the hallways: are we truly more agile than before, or have we just perfected the art of filling out forms?

I remember those early days. Our Scrum was manual, almost artisanal. User stories were written jointly with the Product Owner, we broke them down into tasks, and we got to work. It had its flaws, of course. Our flow was an internal mini-waterfall: Development -> QA Testing -> PO Approval. It was imperfect, sometimes chaotic, but it was human. There was a direct connection and a clear goal: to deliver.

Fast forward to today. We have sophisticated tools, formalized processes, and an agile vocabulary that everyone recites from memory. But that genuine agility feels further away than ever. We've adopted the rituals of Scrum, but we've lost its spirit. We are living in the era of the "Scrum Zombie": we go through the motions, but there's no life.

These are the pain points I believe many will recognize.

Pain Point #1: The Pre-Sprint Gauntlet: Agility by Committee

Before we can write a single line of code, every sprint must survive a bureaucratic maze I call the "sprint before the sprint."

The Justification Kickoff: A meeting where the PO must "sell" the sprint's value, justifying the investment, calculating ROI, and savings in manual hours. It feels less like the start of an iterative cycle and more like a defense for an annual budget.
The Costing and Planning Review: A detailed analysis of costs and timelines that reeks of the waterfall project management we were supposed to leave behind.
The PMO's Blessing: Finally, a stamp of approval from the Project Management Office that adds another layer of waiting and bureaucracy.

The Diagnosis: This isn't agility. It's the traditional project management mindset using Scrum terminology. It prioritizes control and prediction over adaptation and rapid value delivery, which are the heart of agility.

Pain Point #2: The Daily That Became a Status Meeting (While Seated, of Course)

I remember when dailies were 15-minute meetings, standing up, with a single purpose: what blockers do we have, and how can we help each other overcome them?

Today's Reality: Those meetings have morphed into 30-to-45-minute sessions. The team no longer collaborates to solve problems; each member reports their status to management. The focus is no longer "how do we move forward together?" but rather "did you justify the hours you were assigned yesterday?".

The Diagnosis: This is a symptom of a lack of trust. When the daily becomes a status report, the team's self-organization dies. The Scrum Master (or whoever leads the meeting) has shifted from a facilitator who removes impediments to a foreman who oversees progress.

Pain Point #3: The Sprint as a Two-Week Mini-Waterfall

This is a problem that has persisted over the years. Although the tools have changed, the underlying workflow remains the same.

The Reality: Work flows in one direction: all development is completed, then everything moves to QA, and finally, everything is delivered to the PO for approval. A story doesn't move forward until all its tasks are done, and the sprint doesn't end until all stories are approved.

The Diagnosis: This creates massive bottlenecks and delays crucial feedback. True agility aims for a cross-functional team (developers, QA, etc.) to work on a single story until it is completely done (meeting a robust "Definition of Done") before starting the next one. Our model is simply a waterfall with a two-week time limit.

Conclusion: Small Acts of Rebellion to Revive the 'Scrum Zombie'

We can't change the entire organization overnight, but we can start reclaiming the agile spirit with small, pragmatic actions.

Reclaim the Daily Stand-up. The first step is the simplest: go back to 15 minutes. Standing up. With a single goal: identify impediments. Anything else is discussed after the meeting, and only with the necessary people.
Advocate for a Real "Definition of Done." Let's propose in the retrospective that a story is "done" when it is developed AND tested by QA, not just when the developer finishes their part. This forces collaboration, breaks down silos, and focuses us on delivering functional value increments.
Question Bureaucracy with Data. Instead of complaining, let's use the retrospective to measure the time lost. "How many days did we wait for PMO approval this sprint?". Presenting that data isn't a complaint; it's an opportunity for improvement for the entire organization.

A successful sprint isn't one that checks all the ritual boxes, but one that delivers real value to the user and, in the process, teaches us how to be a slightly better team next time.

Do you experience a similar reality in your team? What other "Scrum Zombie" symptoms have you seen? I'd love to read your experiences in the comments.

From 3.5 Hours to 30 Minutes: Optimizing C# with LINQ's ToLookup

Emilio Acevedo — Wed, 15 Oct 2025 01:50:42 +0000

The Silent Bottleneck: From Fast Process to 3.5-Hour Nightmare

In software development, some processes are born fast and efficient, but as data grows over time, they turn into real bottlenecks. This was the case with our AplicarReglasWithAllReferences method, a crucial component in pension calculations that, over the months, went from running in minutes to taking a staggering three and a half hours.

The system became sluggish, users grew impatient, and maintenance became increasingly complex. The culprit wasn't the database or a convoluted business logic, but a very common and dangerously inefficient coding pattern: using .Where() on lists inside a foreach loop.

The Anti-Pattern: Death by a Thousand `.Where()` Cuts in a Loop

The original logic was simple and straightforward. At the beginning of the method, we loaded several large lists of related data into memory: policies, people, exceptions, coverages, etc. Then, we iterated through the main list of policies and, for each one, looked up its related data in the other lists.

The code looked something like this:

// Large lists of data are loaded at the start
IList<Poliza> allPolicies = dao.GetPolicies();
IList<RuleException> allExceptions = dao.GetExceptions();
IList<Coverage> allCoverages = dao.GetCoverages();

foreach (var poliza in allPolicies)
{
    // For EACH policy, the ENTIRE list of exceptions is scanned again
    var exceptionsForPolicy = allExceptions.Where(e => e.IDPoliza == poliza.IDPoliza).ToList();

    // And the ENTIRE list of coverages is scanned again
    var coveragesForPolicy = allCoverages.Where(c => c.IDPoliza == poliza.IDPoliza).ToList();

    // ...do something with the found data...
}

Why is this so slow?

The answer lies in computational complexity. A .Where() on a list performs a linear scan (O(N)). This means that to find an item, it has to check, in the worst case, all N items in the list. If you do this inside a loop that repeats M times, the total complexity skyrockets to O(N * M).

If you have 100,000 policies (M) and 500,000 exceptions (N), the number of operations is astronomical. You're asking the system to read the entire phone book, over and over, for every person you're looking up.

The Elegant Solution: `ToLookup` as a High-Speed Index

The solution to this problem is one of LINQ's most powerful and underrated methods: ToLookup().

ToLookup transforms a list into a dictionary-like structure, but optimized for one-to-many relationships. It works like a book's index: instead of reading the entire book to find a term, you go directly to the correct page.

Implementing this change is surprisingly simple:

One-Time Indexing Cost: Before entering the loop, you convert your secondary data lists into an ILookup. This has an initial cost of O(N) to create the index.
Instantaneous Lookups: Inside the loop, you replace the expensive .Where() with a direct access to the lookup, which is an almost instantaneous operation (O(1)).

The refactored code looks like this:

// Large lists of data are loaded at the start
IList<Poliza> allPolicies = dao.GetPolicies();
IList<RuleException> allExceptions = dao.GetExceptions();
IList<Coverage> allCoverages = dao.GetCoverages();

// 1. The "indexes" are created once before the loop.
var exceptionsLookup = allExceptions.ToLookup(e => e.IDPoliza);
var coveragesLookup = allCoverages.ToLookup(c => c.IDPoliza);

foreach (var poliza in allPolicies)
{
    // 2. The lookup is now instantaneous (O(1)). No more scans.
    var exceptionsForPolicy = exceptionsLookup[poliza.IDPoliza].ToList();
    var coveragesForPolicy = coveragesLookup[poliza.IDPoliza].ToList();

    // ...do something with the found data...
}

The total complexity is now O(N + M), a drastic improvement over O(N * M).

Real-World Results: An 85% Reduction in Execution Time

By applying this technique to our AplicarReglasWithAllReferences method, the results were transformative. The process, which used to paralyze the system for 3.5 hours, now consistently finishes in approximately 30 minutes.

This represents an 85% reduction in execution time, achieved with a minimally invasive yet conceptually powerful code change. We moved from an inefficient algorithm to an optimized one, freeing up system resources and restoring agility to the business process.

Conclusion

If you have a slow process that works with large collections of data in memory, look for this anti-pattern. You'll likely find foreach loops with .Where() calls inside. Replacing them with a pre-calculated ILookup is one of the most effective optimizations you can implement. Not only will you dramatically reduce execution times, but you'll also make your code cleaner and more readable.

Why I'm Learning 3D Graphics After 20 Years in Tech

Emilio Acevedo — Sun, 05 Oct 2025 21:02:23 +0000

Hello, world. My name is Emilio, and I'm a Senior Software Engineer.

For the better part of two decades, my world has been one of databases, APIs, massive processes, CI/CD pipelines, and complex enterprise architectures. I've built robust, scalable, and mission-critical applications. It's been a rewarding career, one that has taught me the value of solid foundations and meticulous design.

But I'm missing something. All this time, I've only created things for others, so I inevitably felt that call, the next step that had to come at some point: the desire to build something completely different. Something visual, interactive, from scratch, and my own.

The Itch to Create

I've always been fascinated by virtual worlds and complex simulations, but my professional path led me down the road of enterprise software. Although it has been rewarding, the desire to build something tangible, something you can see and feel, has always been a quiet hum in the background.

This blog is the public chronicle of that new journey. It's my commitment to stepping out of my comfort zone.

The Mission: Embracing the Junior Mindset

I'm embarking on my most ambitious personal project to date: a large-scale, interactive 3D experience for the web. For now, I'll call it "Project S".

My goal is not just to build it, but to document the entire process in public: the good, the bad, and the buggy. This means embracing the humility of being a beginner again. After 20 years of being the "expert" for backend problems, I'm now the student, facing the intimidating interface of Blender and the endless possibilities of Three.js.

The Toolkit

My arsenal for this adventure will be a mix of the familiar and the completely new:

3D Modeling: Starting from zero with Blender.
Real-time Rendering: Bringing it to life in the browser with Three.js.
Frontend & Blog: This very site (emilioacevedo.dev), built from scratch with Astro.
Backend: Leveraging my experience with Node.js, TypeScript, and modern cloud architecture.

The Promise

So, what can you expect from this space?

This won't be a polished tutorial series. It will be an unfiltered log of a senior developer tackling a new domain. I'll share architectural decisions, frustrating bugs, performance optimizations, 'aha!' moments in Blender, and the raw code behind it all.

If you're a developer curious about 3D, a creative professional interested in the tech, or just someone who enjoys watching a complex project come to life, I'd love for you to join me.

Let's build something cool.