DEV Community: Oussama Ben Sassi

Why Every Engineer Should Learn to Read Research Papers (And How to Start)

Oussama Ben Sassi — Mon, 03 Nov 2025 15:19:45 +0000

You're debugging a performance issue in your microservices. The database queries are slow, but not obviously wrong. You search Stack Overflow, read a blog post or two, implement what seemed reasonable, and the problem gets worse. Then someone mentions an academic paper from 2012 that directly addresses your situation. You read it. The researchers tested exactly this scenario, documented where the optimization works and where it fails, and included a section on production gotchas you'd already hit.

That moment sticks with you. It shouldn't have taken a casual mention to find that information. You had the tools available. You just didn't think to look for them.

This is the core reason engineers should read research papers. Not for some abstract intellectual exercise. Not to impress people at conferences. But because the work that matters in your career has often already been documented, tested, and published. The question is whether you'll find it before or after you burn a week on the wrong approach.

The Real Problem Research Papers Solve

Modern engineering involves picking from an enormous set of tools, patterns, and trade-offs. Most engineers make these choices based on blog posts, conference talks, and what their team happened to use last. There's nothing wrong with that as a starting point. The problem is what happens when the obvious choices stop working.

That's when you need to understand the principles beneath the tools. And that's where research papers live.

AI, container orchestration, database optimization, distributed systems consensus—these didn't start as commercial products or blog posts. They started as peer-reviewed research. Someone designed the thing, tested it carefully, documented what worked and what didn't, and published it. Years later, companies built products around it. Still later, people wrote quick-start guides.

If you read only the quick-start guide, you're working from an interpretation of an interpretation. The actual design decisions, the trade-offs, the known limitations—those live in the original paper.

And here's the practical angle: by the time something becomes common enough for a quick-start guide, you're probably dealing with a problem that guide doesn't cover. That's when you need the research.

Why Engineers Skip This

The barriers are real. Academic papers are dense. They use unfamiliar notation. They assume prior knowledge. And you have actual work to do.

But the barrier isn't as high as it feels. The secret is not reading the entire paper thoroughly. You read strategically.

How to Actually Start

Pick a problem from your current work. Something real, something you're actively thinking about. Don't start with a random paper that sounds interesting. Start with a paper directly related to a problem you have.

If you work with databases, search for papers on indexing strategies or query optimization. If you work with distributed systems, search for papers on consensus algorithms. If you work with deployment infrastructure, search for papers on container orchestration or service discovery.

Existing domain knowledge is your friend here. You already understand the problem. The paper is just showing you how researchers approached it.

When you find a paper, don't read it like a book. Read it like this:

Read the abstract and introduction. This tells you what problem the paper solves and why it matters.
Skip to the results section and look at the diagrams. What did they actually test? What were the performance characteristics?
Read the discussion or limitations section. This is where researchers admit what didn't work and why. This is the most practical part.
Skim the technical sections. You don't need to understand every equation. You need to understand the experimental design well enough to know whether their results apply to your situation.

That's it. You don't need to parse all the mathematical derivations or know every citation in the related work section.

Recognize Academic Conventions

Researchers write with specific constraints. They need to justify everything. They need to be precise even when precision isn't the most readable approach. They structure papers in ways that make sense for peer review, not necessarily for learning.

So filter accordingly. A section that looks like essential reading might be the authors proving a mathematical property they assumed you'd care about. You probably don't. What you care about is whether their testing scenario matches yours and whether their results make sense.

The abstract and conclusion are often the most useful parts. They contain the actual story of what the paper did and why it matters. The middle sections prove it works, but you can usually get away with less depth there than you'd expect.

Use Resources as Pointers, Not Replacements

There are sites and blogs that summarize research papers. They're useful for finding papers and getting initial context. But they're still interpretations. Once you know a paper matters, go read it.

This isn't gatekeeping. It's practical. A blog post about a paper might not cover the specific trade-off you're hitting. The original paper will. Or it won't, and you'll know that faster.

Build the Habit

Don't try to read a paper a week. That's too ambitious when you're starting. Instead, allocate one hour. Pick one paper. Read it using the strategy above. Write a brief note on what the paper solved, how they tested it, and what limitations they found.

That's your actual artifact. Not reading the paper. Writing the note. Because you don't retain information just from reading. You retain it by explaining it.

Over time, papers become easier to read. You recognize the patterns. You get faster at separating what matters from what doesn't. And you start noticing citation chains. This paper cites an older paper that might be even more foundational. Follow those chains. That's how you build real understanding.

Why This Matters for Your Career

Engineers who read research papers debug faster. They make better architectural decisions. They communicate with more confidence about why they're choosing one approach over another. They're less likely to spend a week optimizing something that's fundamentally limited by the approach itself.

They also tend to get promoted faster. Not because they're smarter. But because they can explain technical decisions in terms of actual trade-offs rather than hunches or hype.

This is practical professional development. It's not separate from your job. It's literally how you get better at your job.

Start this week. Find a paper related to something you're working on. Read the abstract and jump to the results. Spend thirty minutes on it. See if it gives you any insight you didn't have before. Most of the time it won't help immediately. Sometimes it changes how you think about a problem.

That's the point. You're not looking for immediate impact. You're building the habit and the pattern recognition to spot when a paper matters.

Convolutional Neural Networks: How Does AI Understand Images?

Oussama Ben Sassi — Sat, 14 Sep 2024 11:29:40 +0000

Have you ever asked yourself how AI systems can understand images? Like how they can tell whether an animal in a picture is a cat or a dog?

Recently, I’ve been learning about deep learning through a TensorFlow course by IBM on edX, and I’ve been really amazed by how powerful Convolutional Neural Networks (CNNs) are in recognizing images.

If you're a developer, no matter your background, I think you’ll find CNNs both interesting and very useful.

In this article, I want to guide you through the basics of how CNNs work, breaking down each layer to show you how they can classify images.

What Is a Convolutional Neural Network (CNN)?

A CNN is a type of artificial neural network specifically designed to process and classify visual data,

CNNs are great at capturing patterns like edges, textures, and shapes which makes them perfect for tasks like identifying objects in pictures or distinguishing between a cat and a dog.

The Building Blocks of a CNN

A CNN is made up of several layers, each serving a different purpose:

1. Convolutional Layer

Of course, Every image you see is made up of pixels. A pixel is the smallest part of a digital image, and each one holds a number.

In a grayscale image, each pixel has a value between 0 and 255, representing a single channel of intensity. For a colored image (RGB), each pixel has three channels (Red, Green, Blue), with each channel holding a value between 0 and 255.

In this layer, A CNN uses something called a filter or kernel (small matrices of numbers) that moves over the image, applying a dot product operation on the pixels to detect specific patterns, as shown in the image below:

Typically, we initialize the kernels with random values, and during the training phase, the values will be updated with optimum values.

Why Sliding Matters

The sliding motion of the filter across the image allows the CNN to learn spatial hierarchies of patterns.

As the filter moves, it captures basic features like edges in the early layers and more complex patterns, such as shapes or objects, in deeper layers.

For example, applying different kernels to the digit 2 can highlight various patterns:

As you see in the image above, applying those filters to an image highlights its edges, creating a new image (in CNN terms, a feature map), that represents the detected features.

This process, known as convolution, results in a feature map that shows the detected features in the image.

2. ReLU Activation:

After the convolution step, where the CNN identifies patterns like edges or textures, we need to decide which patterns are important. This is where ReLU (Rectified Linear Unit) comes in.

What Does ReLU Do ?

Think of ReLU as a filter that cleans up the image further. After the convolution layer finds patterns, some of those patterns are helpful (positive values) and some are not useful (negative values)

The ReLU layer takes the output from the convolution layer and simply changes all the negative values to zero as shown in the image below:

By doing this, ReLU discards the unhelpful parts, keeping only the meaningful patterns, But ReLU’s impact goes beyond just setting negatives to zero—it introduces non-linearity into the model,

What Does Non-Linearity Mean ?

If you were to only draw straight lines, you’d miss out on capturing the curves and complexities of real-world objects. A linear function sees only straightforward, flat changes, like a gradual slope.

For example, picture a shadow or a gradient on an image. A linear function would only see it as a flat, dull line of change.

ReLU, by cutting off negative values, highlights differences more sharply, helping the CNN to “see” and react to those changes in more dynamic ways. in other words, it can start capturing rounded shapes, complex textures, or variations.

So, ReLU helps the CNN "break out" of basic, straight-line thinking, allowing the model process images in a richer, more detailed way—much like how our brains can see the fine differences between shadows, colors, and textures.

3. Pooling Layer:

Next up is the Pooling layer, which is used to reduce the spatial dimensions (height and width) of the feature maps as shown in the image above.

This layer helps to make the CNN more computationally efficient by reducing the number of parameters and ensuring that the model focuses on the most important features.

How does it work ?

The most common pooling method is Max-Pooling, which selects the highest value in a small window (e.g., 2x2) and slides it across the feature map, creating a smaller, downsampled version

4. Fully-Connected Layer:

After the convolution and pooling layers have extracted the relevant features from the image, the final step is classification. This is done by the Fully-Connected layer.

How does it actually work ?

1. Flattening :

First, the high-level features (like shapes and patterns) extracted by the previous layers are flattened into a single, long list of numbers:

Why do we need flattening layers?, so the network can consider all the features together, which helps in making a final decision or classification.

2. Processing Through Neurons

Once flattened, the data is passed through the Fully-Connected layers. Each neuron in these layers is connected to every neuron in the previous layer, This means the FC layer can look at all the features at once and understand how they relate to each other.

Each neuron receives inputs from all the neurons in the previous layer. These inputs are multiplied by weights, Weights are numbers that tell the network how important each feature is. These weights are learned during training to improve the network's accuracy.

The results are then summed up with a small value called a bias, The bias helps by shifting the neuron's activation threshold, allowing it to still respond appropriately even if the input values aren't perfect.

This flexibility helps the model adjust better to the data.

3. Decision Making with Softmax activation function:

In the final step, the last FC layer outputs a set of scores, one for each possible class. The Softmax function is then applied to these scores, converting them into probabilities. The class with the highest probability is selected as the network’s final prediction.

In summary, the Fully-Connected layers integrate all extracted features, perform complex transformations, and make the final classification decision using probabilities.

Conclusion ✨

At its core, a CNN is just a series of numbers and math, but those numbers allow it to "see" and interpret images in incredible ways. I hope you now have a good idea of the deep learning world, especially CNNs.

As a bonus, if you’re looking to dive deeper, feel free to check out my Deep Learning with TensorFlow GitHub repo, which contains Jupyter Notebook labs from the "Deep Learning with TensorFlow" course by IBM on edX, and my Machine Learning with Python repo, featuring labs from IBM's Coursera course.

If you have any questions or just want to chat more about it, feel free to reach out. Thanks for reading 😊.

Beginner’s Guide to Implementing a Simple Machine Learning Project

Oussama Ben Sassi — Thu, 25 Jul 2024 09:25:28 +0000

I completed few days ago the "Machine Learning with Python" course by IBM on Coursera. And Because this field can seem quite challenging for many, I decided to write a set of simple, concise, and fun articles to share my knowledge and guide new learners in the machine learning field!

In this easy, fun, and simple-to-understand guide, I will unravel the mystery of machine learning by helping you create your first project: predicting customer categories for a telecommunications provider company.

Setting Up Your Environment

Before we begin, you can use Google Colab to run all the code provided here. This will allow you to execute the code in the cloud and analyze the output directly without using your machine's resources.

Project Overview

Imagine a telecommunications provider has segmented its customer base by service usage patterns, categorizing the customers into four groups:

Basic Service
E-Service
Plus Service
Total Service.

Why Categorize (or Classify) Customers?

Categorizing customers allows a company to tailor offers based on specific needs. For example, new customers might receive welcome discounts, while loyal customers could get exclusive early access to sales.

Our objective in this project is to build a classifier that can classify new customers into one of these four groups based on previously categorized data. For this, we will use a specific type of classification algorithm called K-Nearest Neighbors (kNN).

To learn more about different ML algorithms, check out this informative article: Types of Machine Learning,

Anyway, let the fun begin!

Data

Of course, Machines learn from the data you give them, which is the essence of machine learning algorithms. They analyze data, learn patterns and relationships, and make predictions based on what they've learned.

Downloading and Understanding Our Dataset

To make it easier to understand our dataset, let's first download it and output the first five rows using the Pandas library.

Pandas is a Python library used for working with data sets. It has functions for analyzing, cleaning, exploring, and manipulating data.

So, go ahead and open Google Colab, create a new notebook, and in the first code cell, type:

import pandas as pd
import matplotlib.pyplot as plt # For creating visualizations and plots

and then run it to import the Pandas library.
Next, in the second code cell, type the following code to read the dataset from the provided URL and display the first five rows:

df = pd.read_csv('https://cf-courses-data.s3.us.cloud-object-storage.appdomain.cloud/IBMDeveloperSkillsNetwork-ML0101EN-SkillsNetwork/labs/Module%203/data/teleCust1000t.csv')
df.head()

As you see in the first five rows, we have customers with attributes such as region, age, and marital status. We will use these attributes to predict a new case. In machine learning terminology, these are called features, while the target field (the attribute we want to predict), called custcat (short for customer category), which has four possible values corresponding to the four customer groups we discussed earlier, is known as the label.

Let's perform a quick analysis with Pandas to see how many of each class is in our dataset. Type the following in a new code cell to get the result:

df['custcat'].value_counts()

Extracting Features and Labels

We will use X variable to store our feature set, and Y to store our labels:

import numpy as np
X = df[['region', 'tenure', 'age', 'marital', 'address', 'income', 'ed', 'employ', 'retire', 'gender', 'reside']].values

The line of code above selects specific columns from the DataFrame df to be used as features for our machine learning model.
To see a sample of the data. let's output the first five rows from the array X using X[0:5]

array([[  2.,  13.,  44.,   1.,   9.,  64.,   4.,   5.,   0.,   0.,   2.],
       [  3.,  11.,  33.,   1.,   7., 136.,   5.,   5.,   0.,   0.,   6.],
       [  3.,  68.,  52.,   1.,  24., 116.,   1.,  29.,   0.,   1.,   2.],
       [  2.,  33.,  33.,   0.,  12.,  33.,   2.,   0.,   0.,   1.,   1.],
       [  2.,  23.,  30.,   1.,   9.,  30.,   1.,   2.,   0.,   0.,   4.]])

Now, Let's store the values of our label in Y

y = df['custcat'].values
y[0:5]

Data Standardization

Normalizing our data helps convert it into a uniform format. Why? Because imagine in our raw data we have age in years, income in dollars, and height in centimeters; the algorithm may give more importance to features with larger scales. This can skew the results and lead to a biased model.

The line of code below scales and normalizes the data. It standardizes the features so they have a mean of 0 and a standard deviation of 1. This is a good practice in general.

First, make sure to install scikit-learn library

pip install scikit-learn

Scikit-learn is a library in Python that provides many unsupervised and supervised learning algorithms

Then, Go ahead and the run the code below and see in the output how all the values are unified on similar scale:

from sklearn import preprocessing
X = preprocessing.StandardScaler().fit(X).transform(X.astype(float))
X[0:5]

Again, don't worry if the line above seems complex; the important thing right now is to understand the importance of it 😊.

Train-Test Split

Since we only work with one dataset, Train/Test Split involves splitting our dataset into training data (the data we will give to our model to learn the patterns of it) and testing data (the one we will use for predictions).

In future articles, I’ll cover various and more in-depth evaluation techniques for models, including Train/Test Split, K-Fold Cross-Validation, and more.

So, To perform the Train/Test split, we import it from scikit-learn library

from sklearn.model_selection import train_test_split

And now let's use our imported function and explain what is happenig in the line below:

X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=4)

train_test_split() divides the features (X) and labels (y) into two parts: 80% for training the model (X_train and y_train) and 20% for testing it (X_test and y_test). The random_state=4 ensures that each time you run the code, the split result is the same.

To see the size (number of rows and columns) of our train and test dataset, we will use the .shape attribute:

print('Train set:', X_train.shape,  y_train.shape)
print('Test set:', X_test.shape,  y_test.shape)

Classification

As I mentioned before, we will use K-Nearest Neighbors or (KNN) algorithm to train and to predict new classes.
(If you want to know how this algorithm works, just leave a comment; I’ll be glad to write an article about it 😉)

Good news!, We don't need to implement the algorithm by ourselves as we can easily import the model from the scikit-learn library:

from sklearn.neighbors import KNeighborsClassifier

Training

The block of code below creates a K-Nearest Neighbors model, The fit() method trains the model with the training data (X_train) and its corresponding labels (y_train), allowing the model to learn from this data:

k = 4
neigh = KNeighborsClassifier(n_neighbors = k).fit(X_train,y_train)

Predicting

Now, let's make some predictions!
Let's create a variable named y_predict to store our model’s predictions on the test data we created earlier, We will also use this variable to compare its results with y_test which has the real and correct values. This means we will compare our prediction with the real values to test our model’s accuracy.

y_predict = neigh.predict(X_test)
y_predict[0:5]

Accuracy evaluation

The y_predict[0:5] will output the first five prediction results, you can do some comparison yourself with y_test.

But, Comparing results manually can be error-prone and inconsistent, That’s why Scikit-learn offers various accuracy evaluation methods that standardize this process. For example, metrics.accuracy_score calculates the proportion of correct predictions, providing a clear and objective measure of how well your model performs.

Let's use metrics.accuracy_score to see how well our trained model is working:

from sklearn import metrics

print("Train set Accuracy: ", metrics.accuracy_score(y_train, neigh.predict(X_train)))
print("Test set Accuracy: ", metrics.accuracy_score(y_test, y_predict))

Our code output accuracy scores says that the model correctly predicted the labels for about 54.75% of the training data and correctly predicted the labels for about 32% of the test data.

The large gap between training and test accuracy might suggest overfitting, where the model learns the training data too well but struggles with new, unseen data.

Of course, If time permits, In future articles, I will discuss strategies to improve a model’s accuracy on new, unseen data.

Conclusion ✨

I really hope this guide was easy to follow and I hope it helped you learn something new.

Always keep experimenting and exploring new techniques. There’s always something new to learn in machine learning, and I’m excited to share more with you in future articles.

Feel free to drop your thoughts or questions in the comments. I’m here to help and would love to hear about your experiences and progress.

Happy coding 👨‍💻

Bye for now! 😊

Should Sensitive Systems Be Open Source ?

Oussama Ben Sassi — Mon, 22 Jan 2024 13:16:05 +0000

The other day, I was talking to a friend who's studying computer engineering. We were discussing my open-source project, a small online tool that helps people encrypt their data. During our conversation, my friend dropped a bombshell: "Your app shouldn't be open source." He argued that because my web app's source code is public, anyone can examine it, find weak points, and potentially break into the encryption system.

This led to a lively debate. I'm a big fan of open-source software and had lots to say in its defense. But my friend's comment got me thinking, and I decided to dig deeper into the topic.

In this article, I'll explore whether sharing my encryption app's code with the public is a risk. I'll also look at the bigger question of whether it's better for sensitive systems like encryption apps to be open for everyone to see or kept private.

Closed Source for Sensitive Software
Why Hiding system design Isn't a Reliable Security Strategy
Should Sensitive Systems Be Open Source ?
Defense in Depth principle
- So how can I apply Defense in Depth approach in open-source model ?
Conclusion

Closed Source for Sensitive Software

The term is self-explanatory, but let's look at its definition:

Closed source refers to a type of software whose source code is not made available to the public or users. In closed-source software, users are not allowed to copy, delete, or modify parts of the source code.

Of course, Closed-source software comes with several advantages, particularly when dealing with sensitive applications:

Enhanced Security: Closed-source software provides an extra layer of security by keeping the source code confidential, making it much harder for attackers to find weaknesses.
Control: With closed source, you get to decide who can use your software. This helps keep it away from unauthorized users and protects sensitive data.
Quick Issue Fixes: If a problem is found in your software, you can fix it quickly.
Focused Development: Without constant public feedback, developers can focus on building a strong and secure foundation for your software.

But, even with these advantages of closed source, it's good to question whether relying solely on the secrecy of system design is a reliable security strategy, posing the question of:

Why Hiding system design Isn't a Reliable Security Strategy

Imagine you have a secret, like a special hiding place for your favorite toy. You don't tell anyone about it, and you hope that because it's a secret, nobody will find your toy.

Now, the problem with this approach is that if someone accidentally stumbles upon your hiding place or figures out your secret, they can easily take your toy. So, it's not a reliable way to keep things safe.

So, when a system relies on secrecy rather than the strength of its security measures, it hides vulnerabilities and weaknesses from detection. This lack of transparency means that issues may remain undiscovered until a breach occurs.

A determined attacker (like me, lol) can go to great lengths to discover hidden secrets. Just like someone might search diligently for your hidden toy, hackers can use various techniques to uncover hidden system details. Once they do, the security crumbles.

So, to sum it up, security through obscurity is discouraged because it relies on secrecy alone, which can be easily breached if discovered.

So, does this mean

Should Sensitive Systems Be Open Source ?

This is a complex question, and there isn't a simple answer. However, I've done my best to provide a thoughtful response.

Let's begin by briefly compare the advantages and disadvantages of open-sourcing sensitive systems, starting with the advantages:

Community Auditing: With an open-source approach, the global community of a diverse range of developers and security professionals can actively review and audit the code and that will result in a more robust and secure system.
Faster Issue Resolution: In an open-source model, if a vulnerability is discovered, it can be addressed quickly by the community.
Transparency: Open-source software allows users to see how the software works, which can build trust and confidence in its functionality.

Unfortunately, there are disadvantages, with one of the biggest being:

Target for Attackers: Exposing the source code of sensitive software can make it easier for attackers to exploit vulnerabilities. and so It requires a proactive and vigilant community to stay ahead of potential threats.
Potential Misuse: Open-sourcing sensitive software, like encryption apps,exposes the code to potential misuse by attackers.
Maintenance challenges: Maintaining a large open source project can be challenging, as it requires coordinating the work of a diverse group of developers, ensuring continuous updates, responding to issues, and managing the community involvement can be resource-intensive.
This can be particularly difficult for sensitive software, where security and reliability are paramount.

So, we understand that open-sourcing software can be both an advantage and disadvantage for security. Therefore, there is no direct answer.

If you have a sensitive software and are unsure whether to open source it, consider factors like the level of community support available, the maturity of the software (is the software still under development or stable?), and the capabilities of the development team. Think carefully before making your decision.

Wait, the article isn't finished yet! 😃

Because, as an open-source lover and advocate, I encourage open sourcing, introducing:

Defense in Depth principle

The Defense in Depth principle is a cybersecurity strategy that involves implementing multiple layers of security measures to protect a system, rather than relying on a single security measure, multiple layers are implemented to create a more resilient defense against potential threats.
These layers include technology, procedures, and people. The goal is to prevent, detect, and mitigate attacks at different layers of the system.

So how can I apply Defense in Depth approach in open-source model ?

We can define the layers of an open-source software as the Community Layer, Operational or Procedural Layer, and the Code Layer.

1- Community Layer
As mentioned earlier, the community can conduct code reviews and security audits to identify potential issues and improve overall security.
So encourage your community members to prioritize writing secure code and actively report any vulnerabilities they discover.
2- Operational Layer:
Simply by conducting regular security audits and to use automated tools like static code analyzers and dependency scanners to catch common vulnerabilities early in the development process, reducing the risk of exploitation.
3- Code Layer:
Learn how to write secure code by applying Secure Coding Practices like input validation, error handling and logging, encrypting sensitive data, and much more.

Another crucial aspect: In case of an attack, develop an Incident Response Plan where you define the steps to take in the event of a security incident to mitigate potential damage.

By applying these measures, you can confidently open source your software and enjoy the benefits of community collaboration, security, rapid development, learning, and skill development, and much more.

Conclusion

The article may seem simple to write, but trust me, it was a bit challenging due to the complexity of the topic. The decision to open source a project involves careful consideration. However, you can always embrace the Defense in Depth strategy for securing sensitive systems when opting for open source.

Thank you for investing your precious time in reading my article. I truly appreciate your engagement, whether through questions, critiques, or sharing your opinions and ideas in the comments. I look forward to hearing your perspectives below. Happy coding and securing! 😊

Every change breaks someone's workflow

Oussama Ben Sassi — Sun, 01 Oct 2023 11:53:31 +0000

During my recent internship, I found myself working on the company's human resource management system. They trusted me enough to give me access to the whole project and even allowed me to make changes directly to the live system. One seemingly simple task, however, turned into a valuable lesson about the unintended consequences of software changes, a lesson perfectly encapsulated by Hyrum's Law.

In this article, I'll share with you my experience and how I came to understand Hyrum's Law while working on this HR system.

The Problem

One of my tasks involved the section responsible for handling leave and time-off requests. The system had a specific behavior: when an employee applied for leave while there was already a pending request, it displayed an error message to the user, saying there was a pending leave request. Simultaneously, the system sent an error code and a message to the admin dashboard, informing them of the pending request and prompting them to accept or reject it.

As I started refactoring the code, I realized that the system was in a bit of a mess. It was outdated, and the prevailing mindset was "if it works, don't touch it." This mindset, I soon discovered, was not always correct, and I will write an article about it. Anyway, During the refactoring, I made a seemingly small change to the admin's notification message.

The original message was vague, merely indicating a pending leave request without mentioning the employee's name or the request date. In an attempt to make it clearer and more professional, I added these details to the message. Little did I know, this small change would lead to significant issues.

Every Change Breaks Someone's Workflow

It turned out that one of the admins responsible for managing leave requests rarely logged into the system. Instead, he had written a code that sent him an email notification whenever a leave request was pending. The catch was that he relied on the specific text in the message, not the error code. So, when I changed the message text, he stopped receiving emails, and consequently, he had no idea about pending requests.

Fixing the Problem

Around two weeks after my change, the admin finally noticed the issue and reported it to my supervisor. Fortunately, I had been diligently maintaining a changelog file for every modification I made. With the help of this changelog file, my supervisor quickly identified the problem and updated the admin's code to match the new message format. Finally, everything started working smoothly again.

Hyrum's Law in Action

This experience led me to explore how others manage to work on complex systems without inadvertently causing disruptions. That's when I stumbled upon Hyrum's Law, which perfectly described what I had gone through.

The law says that:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody.

In simple terms, Hyrum's Law states that when a sufficient number of users rely on an aspect of your system, regardless of what your official documentation or promises say, all observable behaviors of your system will become essential to someone.

Understanding My Situation Through Hyrum's Law

Hyrum's Law helped me make sense of what happened during my internship. Here's how it worked in my situation:

The admin had, without formal documentation, established a dependency on the message text. He had come to expect the message in a specific format, and my modification broke that unwritten contract. This was the essence of Hyrum's Law in action: the observable behavior of the system, regardless of official documentation, became critical to someone's workflow.

From my experience, I learned that you should be very careful when you make changes that means you should understand how things are connected and communicate your changes to others.

Conclusion and Advice

My internship and this exact experience taught me some important lessons, and I want to share them with you:

Write Down What You Change: Keep a list of all the things you change in a system. It can help you fix problems later, like it did for me.
Respect What's Already There: Remember that people might be using things you didn't even know were important. Be careful when you change stuff.
Talk to Your Team: Don't keep your changes a secret. Talk to your team and let them know what you're doing. They might have good ideas or warn you about problems.
Test Before You Make It Official: Try out your changes in a safe place first. That way, you can see if they cause any problems.
Balance New and Old: It's good to make things better, but don't break what's already working. Find a balance between making new stuff and keeping the old stuff working.

Hyrum's Law reminds us that even small changes can have big consequences. So, be careful and think about how your changes will affect everything around them. This way, you can make sure everything keeps working smoothly.

That's it for today! 😊 I hope you found this article helpful and gained some useful insights. If you have questions or if you've faced similar challenges, don't hesitate to share your thoughts in the comments below. I'm excited to read your comments and eager to hear any suggestions you might have for making this article even better. Happy coding!

Your process is never faster than its slowest part.

Oussama Ben Sassi — Tue, 26 Sep 2023 13:36:59 +0000

The Problem

The other day, I was working on an old project of mine on GitHub. This project had a lot of tasks to do, but the whole program was designed to run one task at a time, one after the other. It was slow, and I wasn't happy with how I had programmed it in the past (maybe because I was new to programming back then). So, I decided to break the program into smaller tasks, hoping to make it faster and improve its performance.

The Before and After Measurement

Before making any changes, I measured how long it took for the program to finish its job. After I finished optimizing it, I measured the time again, and I was surprised to find that the execution time remained the same both before and after the changes. Why did this happen?

Amdahl's Law: The Key Insight

As I looked into why this happened, I came across something called "Amdahl's Law."

from wikipedia :

In computer architecture, Amdahl's law (or Amdahl's argument) is a formula which gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved.

Now, let's simplify this:

Amdahl's Law tells us that the overall speedup we can achieve by parallelizing a program is limited by the portion of the program that cannot be parallelized

So let's take a simple example:

imagine you have a race with different parts, like running and swimming. Amdahl's Law is like saying, "Your overall race time can never be faster than your slowest part of the race." In other words, even if you're really fast at running, if you're slow at swimming, your race won't be faster overall

The Parallelism Pitfall

in my case, the program was initially entirely sequential, meaning it had no inherent parallelism. When I divided it into smaller tasks, I introduced parallelism, which should theoretically lead to faster execution. However, here's the catch: Amdahl's Law reminds us that if a significant portion of the program still remains sequential and cannot be parallelized, the speedup will be limited.

Confronting Sequential Bottlenecks

in my scenario, I have found that a part of my program couldn't be broken down into smaller parallel tasks due to dependencies on other tasks. This non-parallelizable portion acted as bottleneck, preventing the program from running significantly faster, no matter how well-optimized the parallelizable parts were.

So, Amdahl's Law helped me understand that simply breaking down the program into smaller tasks and parallelizing it wouldn't yield the desired performance improvements. To make the program faster, I needed to identify and address the sequential bottlenecks that were holding it back. In essence, Amdahl's Law taught me that true performance gains require a comprehensive understanding of a program's limitations, not just a superficial attempt at parallelism.

Conclusion

In conclusion, let's sum up the important lessons i've learned about parallel programming in simpler terms:

Before you try to make your software faster with parallelism, Check if the program can be divided into smaller independent tasks and these individual tasks can be executed concurrently and independently. If you can do this, then this type of program can take advantage of parallel computing.
If your program can't be split into independent tasks, then parallelism won't help much. Some programs just can't be made parallel.
Identify the Performance Bottlenecks, these bottlenecks often hide in sequential portions of your program, which, if left unaddressed, can limit your optimization efforts.
You need to have deep understanding of your program's limitations.
Remember that parallelism isn't always the answer. If your program is small and simple, it might be better to keep it sequential. Parallel programming can be a lot more complicated, with threads and processes to manage, and tricky problems to solve.

That's all for now! 😊 I hope you've gained some valuable insights from this article. If you have any questions or if you've encountered similar challenges, please feel free to share them in the comments. I'm eager to read and respond to your comments, and I'm open to any suggestions you may have to improve this article. Happy coding!.