Eat What You Kill

Introduction

Often, when I explain a computer science concept to less technical people, I look for analogies. People tend to have that imaginary barrier that prevents them from understanding some “simple” ideas that they decided upfront were too hard to grasp.

Explaining things such as “asynchronous” or “parallel” often leads to a restaurant or similar analogy. The abstraction API provides can be presented with the bar, waiter, and the kitchen somewhere in the back, which you cannot see, don’t know, and, most of the time, do not care how it operates. There could be some more everyday examples, but what can I say? I am a big fan of food and drinks.

We saw that real-life examples can explain patterns in computer science. But can we use CS concepts to clarify or improve our daily work? Let’s find out by investigating threading and parallelization strategies.

EWYK Explained

Instead of a centralized thread pool where tasks are evenly distributed (i.e., using a round-robin or queue-based strategy), this threading model allows worker threads to self-assign tasks dynamically. This means that, instead of waiting for a dispatcher, threads take tasks when they are ready, avoiding idle time. It is worth noting that threads don’t wait for work. They take the next thing they “see” when they finish their current tasks. Without a centralized dispatcher, there is a less “hops”, as the threads pick up tasks when they are available and do not wait for command or approval to start. However, this does not eliminate disbalance or inefficiencies.

This simple yet efficient model sounds like a queue, but it is not, as it requires less synchronization. In the queue approach, some workers can become overloaded while others are idle if we are not careful. With the EWYK, the high-performing workers are assigned more work, while the slow ones do not get additional work until they finish their current tasks. EWYK does not provide equal work distribution, but it is according to its purpose, as the goal is to be as efficient as possible and not to distribute work fairly.

Do not be mistaken: Queues can be efficient, like any other strategy, if implemented correctly. However, due to common synchronization issues, this is often not easy.

Not everything is ideal with EWYK’s, and it’s far from being a silver bullet. Among a few notable downsides, the most common one is thread starvation, where some threads are much faster, and the rewarding algorithm leads them to do all the work while the slower one does not get any. This approach is also not suitable for sequential tasks.

Using EWYK to Organize Work

Surprisingly (or not), the first thing that comes to mind when talking about the workload, tasks, and reward is something like sales or any other work with measurable KPIs (Key Performance Indicators), which are used to incentivize the service provided and goals achieved. You get more work for a good job, but you are rewarded accordingly.

Another point that rings the bell is “not fair, but efficient,” as the incentivization is not designed to distribute profit or rewards equally but to motivate people to work harder. Naturally, more efficient people will be more profitable, but they will do more work.

IT World

In the programming world, this is the strategy where the developers are directly rewarded for their contributions to the code, completing tasks, delivering features, or whatever can be found measurable. Again, in the programming world, good Program Managers are aware that calculating KPI is not easy. Most of them avoid it because of the complexity and because they do not show the whole picture accurately. It cannot be simply lines of code, number of tasks, or points… there is a lot to it, and the best of the best understands this well.

When this approach is applied to the development cycle, the developers take full responsibility and ownership of their code to ensure meaningful measures. There is less “administration” (bureaucracy?). The focus is on delivery, with efficiency being the key. We often see this in the world of startups and contractors. Usually, freelancer contractors are paid by milestones or hourly rather than a fixed salary.

The common issue is burnout, while the business side can suffer if not careful. Deliverables can drop in quality due to focusing on speed and taking shortcuts instead of creating the best solution. However, this strategy is common and valid in startups, where some tradeoffs are acceptable, and the focus is on getting to the market as fast as possible.

Conclusion

Does this mean we found the ideal work distribution? Not. Many things can go wrong, and according to Murphy’s Law, they will. Things like cherry-picking, which involves taking the most profitable tasks for the least effort, will always be present. Not all people play nice, so they undermine others instead of focusing on their work. This demotivates the target and consequently increases the attacker’s gain unfairly. This is the worst scenario for the employer.

Will this strategy work for your company? It depends on many factors, but it is one of the best strategies to consider when focusing primarily on efficiency. Of course, let’s not forget that the best strategy is the one that works for you, and not all strategies are suitable for use cases.