Forem: Deepak Singh

🚀 How I Built My Dream Chrome Extension Template in 36 Hours — Thanks to Kiro

Deepak Singh — Wed, 19 Nov 2025 14:33:56 +0000

For the past two years, I’ve wanted to build real Chrome extensions.
I had ideas. I had excitement. I had big plans.

But I didn’t have the direction, the resources, or the right tooling to turn those ideas into reality. Chrome extensions—especially modern, Manifest V3 extensions—come with complicated architecture, annoying setup tasks, and limited documentation.

So, like many of my ideas…
I dropped everything.

But then came the Kiroween Hackathon.

And in just 36 hours, I built the Chrome extension development template I’d been dreaming about for two years:

🎉 Extension Bro — Skeleton Crew

A luxury, production-ready, AI-capable, React + Vite + TypeScript Chrome extension template with a generator, design system, and two real working extensions.

This is the story of how I built it, what I learned, and how Kiro changed everything.

🎃 The Spark That Started It All

When the hackathon began, I decided:

“This time, I’m doing it. No excuses.”

I had always struggled with Chrome extension architecture:

Setting up React + Vite the correct way

Handling Manifest V3 service workers

Managing popup → background → content messaging

Chrome storage

Icons

Build scripts

AI integration

These pain points killed my motivation again and again.

But with Kiro, something clicked.

💡 Kiro was a game changer

Here’s the polished version of what I’ve told many people already:

Kiro was a game changer for me. For the past two years, I had many ideas for Chrome extensions, but due to the limitations of Chrome extensions and the lack of available resources, I dropped everything. However, in this hackathon, I decided to give it a try—and it worked. The steering really helped me create a highly optimized and production-ready extension template that I can use to build more complex Chrome extensions in the future.

This hackathon gave me a reason, but Kiro gave me the ability.

🧪 How Kiro Supercharged My Development Process
🔧 1. Vibe Coding — Fixing UI, Bugs, and Optimization

Whenever the UI felt off—or something just wasn’t working right—I used vibe coding to quickly refine things.

The bundle size reduction blew my mind.
Suddenly, my extension felt like a SaaS-level product.

🧩 2. Agent Hooks — My Secret Weapon

Hooks saved me hours of debugging.

“Agent hooks helped me a lot, as did Kiro itself. I set up hooks so that I could get the desired output and write code properly. Sometimes small mistakes—like casing issues—can waste hours, so I configured hooks to prevent these kinds of errors.”

Hooks ensured consistency.
They ensured correctness.
They made Kiro predictable and reliable.

🧠 3. Steering — The Real Superpower

Steering is where the magic happened.

With steering, I could:

Constrain Kiro when I wanted minimal UI

Boost Kiro when I wanted animations

Change design rules

Define component quality

Declare color palettes

Lock in architecture decisions

As I said:

“I used steering both to constrain Kiro and to boost it, because not every project requires the same things. Sometimes I want a very simple, basic UI, and other times I want animations—so steering helped me adjust that easily. The strategy that worked best for me was clearly defining requirements, such as design style, color themes, and other details.”

This gave me SaaS-level design quality with AI-level speed.

🤯 The Moment That Blew My Mind

There was one experience that changed everything.

I wrote a single prompt, asked for an AI-powered, polished extension UI—and Kiro generated nearly the entire working extension.

Just… like… that.

“That was something that completely blew my mind. I literally coded a fully working, AI-integrated, beautifully designed extension with just one prompt and two revisions. A well-structured template + hooks + steering = insane productivity.”

This made me realize:
With the right structure, AI becomes 10x more powerful.

🧱 What I Built in 36 Hours

Let me break down Extension Bro — Skeleton Crew:

✔️ React + Vite + TypeScript Architecture
Fully typed
Multi-entry Vite build
Popup + content scripts + service worker
Optimized rollup output
Hot Reload for popup (HMR)
Tailwind design tokens & luxury theme
Gold, glassmorphism, gradients, animations

✔️ A Generator CLI

Run:

node generate-bro.js

And you get:

New extension folder

Manifest updated

Icons generated

Dependencies installed

Ready-to-run dev server

Clean structure with no build artifacts

✔️ AI Features

I built two example extensions:

Is True? — AI Fact Checker

@google/genai integration

Select text → Right-click → Verify

Verdict + confidence

Beautiful modal

Spam Detector 🛡️

Real-time background analysis

Page scanning

Warning overlay system

Persistent toggle state

All built on top of my template.

⚙️ Technologies I Used

React 18
TypeScript
Vite
Tailwind CSS
Manifest V3
Google Gemini AI
Node.js (for generator)
Kiro steering, hooks, vibe coding

📦 How You Can Use Extension Bro

You can build:

AI-powered extensions

Productivity tools

Security scanners

UI-enhancement extensions

Screenshot tools

Translators

Context menu utilities

Run the generator and start coding.

🔮 Future Plans

This is just the beginning.

🌐 1. Multi-language Support

I want to add templates for:

Vue

Svelte

Solid

Vanilla TypeScript

🧱 2. Drag-and-Drop Chrome Extension Builder

This is my ultimate vision:

A UI builder where you drag components, and the system automatically generates a Chrome extension using my template + AI.

Imagine building extensions like:
Webflow → Chrome Extensions.

That’s my dream.

❤️ Final Thoughts

This hackathon helped me create something I’ve wanted for years.
Kiro helped me structure, build, polish, and perfect a template I can use forever.

A template I can extend.
A template I can teach others with.
A template I can turn into a full product later.

If you want to check out the project, here it is:

👉 GitHub: https://github.com/openmediaveris-deepak/Extension-Bro

Thanks to Kiro, the Kiroween Hackathon, and the community for giving me the push I needed.

If you liked this, feel free to drop a comment or star the repo.
More extensions are coming soon 👻✨

Building Tantrik — A Multi-Agent AI Halloween Chat Using Next.js, Flask & Kiro

Deepak Singh — Mon, 17 Nov 2025 10:01:00 +0000

Talk to Dracula, Grim Reaper & Bloody Mary — each powered by their own AI agent.

Halloween should be felt, not just seen.

So I built Tantrik — a web experience where you can actually chat with supernatural spirits, each with unique personalities, sounds, animations, and moods.

Live App → https://tantrik-web.vercel.app

Source Code → https://github.com/luexclothings-hue/tantrik

👻 What is Tantrik?

A fully immersive Halloween spirit-chat platform where users talk to:

🧛 Count Dracula – ancient, poetic, blood-obsessed
💀 Grim Reaper – cold, judgmental, metaphor-heavy
👰 Bloody Mary – unpredictable, whispery, mirror-themed

Each spirit has:

Its own AI agent
Custom system prompt
Animated background scene
Spirit-specific ambience + horror sounds
Themed UI + color psychology

🧱 Architecture Overview

tantrik/
├── tantrik_web/ # Next.js 16 + React + TS frontend
└── tantrik_ai/ # Flask backend with multi-agent AI

🔮 Multi-Agent AI Backend (Flask + OpenAI)

Tantrik doesn’t use one model pretending to be everyone — I built separate AI agents for each spirit.

Base agent

class SpiritAgent:
    def __init__(self, name, system_prompt, primary_api_key, model, temperature):
        self.name = name
        self.system_prompt = system_prompt
        self.model = model
        self.temperature = temperature

Dracula example

class DraculaAgent(SpiritAgent):
    def __init__(self, primary_api_key):
        super().__init__(
            name="Count Dracula",
            system_prompt=DRACULA_SYSTEM_PROMPT,
            primary_api_key=primary_api_key,
            model="gpt-4o-mini",
            temperature=0.9
        )

1.Why separate agents?
2.Faster
3.Cheaper
4.No personality mixing
5.Better consistency

🎨 Immersive Halloween Frontend (Next.js 16)

Frontend stack:
Next.js App Router
React 19 + TypeScript
Tailwind CSS
Streaming chat UI

Horror animations (blood drips, flickers, cracked mirrors)
Custom sound engine (ambience + effects)
All wrapped in a Halloween color psychology theme:
Mystic Purple (#8B5CF6)
Blood Red (#DC2626)
Pumpkin Orange (#FF6B35)
Shadow Black (#0A0612)

⚙️ How Kiro Helped Me Build Tantrik

Kiro became my AI development partner.

✔️ Hook System

onCheck → Prevent duplicate components, enforce naming rules, block non-Halloween colors
onGenerate → Ensure theme compliance during generation, log all files
onSave → Formatting warnings, missing semicolons, TODO detection

✔️ Steering Docs

I wrote full guides:
Coding style
Dev rules
Agent architecture
Theme system This made Kiro produce consistent, on-brand code automatically.

😂 Fun Bugs

Dracula once said “bro”
Grim Reaper used “lol”
Bloody Mary gave relationship advice
First blood animation looked like ketchup

🚀 What’s Next

Seasonal themes (Christmas, New Year spirits)
Live voice chat with spirits
AR “mirror ghost” mode
More AI entities

🧡 Final Thoughts

Tantrik showed me how powerful multi-agent systems + theme design + Kiro automation can be.

If you want to build something atmospheric, weird, creative — this is your sign.

“The spirits always listen…
but they only answer in darkness.” 👻

🎃 Transforming the Web Into a Spooky World — Building Halloween Vibes with Kiro

Deepak Singh — Sun, 16 Nov 2025 14:04:23 +0000

For this Hackathon kiroween, I wanted to build something fun, atmospheric, and full of personality. Halloween has always been about eerie visuals, creepy sounds, and unexpected jump scares — so why not bring that experience to any website on the internet?

That’s how Halloween Vibes was born: a Chrome extension that instantly transforms ordinary webpages into a magical, spooky Halloween universe. 👻🕸️

Halloween is all about atmosphere — the glowing pumpkins, flickering lights, creepy whispers, and things that move when you’re not looking. I wanted to capture that feeling and bring it directly into the browser.

Instead of a static theme or wallpaper, I envisioned something alive, animated, and reactive. Halloween Vibes became my way of turning the entire web into a fully immersive haunted experience.

🎃 What It Does

Halloween Vibes overlays spooky decorations, sounds, and animations onto any website without breaking the layout.

✨ Key Features

👻 Visual Magic

Floating pumpkins, ghosts, bats, leaves, witches
Spider webs in all corners
Special Halloween cursors

🔊 Audio Effects

Ambient spooky music

Jump-scare screams & whispers

Tab-aware audio (pauses when switching tabs)

All sounds fully user-controlled

😱 Jump Scares

Flying skulls

Peeking zombies

Bloody Mary crack animations

🧠 Smart Engine

Overlay mode keeps original site styles intact

Per-tab sound management

Autoplay-compliant audio

Lightning-fast injection (under 50ms)

💻 Developer Friendly

React + TypeScript
Vite
Tailwind CSS
Framer Motion for animations

Halloween Vibes uses a modern Chrome extension structure:

React 18 + TypeScript for the popup UI
Vite for fast development & builds
Framer Motion for smooth animations
Chrome Storage API for settings
Web Audio API for sound playback
Content Script to inject decorations onto any webpage
Background Service Worker to manage global state The content script handles the Halloween overlay, animations, decorations, and jump scare logic, while the popup allows users to toggle sounds or switch modes.

😅 Challenges
🔊 Sound System Challenges

Preventing duplicated audio across multiple tabs

Keeping jump scare sounds synced

Handling autoplay restrictions

Ensuring sound toggles worked per-tab

Integrating React + Vite + Manifest V3

Avoiding broken layouts while injecting visual effects

Working around strict CSP websites

Managing performance so animations stayed smooth

A clean, polished Halloween extension that works on most websites

Smooth animations and overlays that don’t break page layouts

A lightweight jump scare system under 10MB memory

Fast injection speed: <50ms

A responsive popup UI

Fully tab-aware sound engine

📚 Learnings

- Dealing with browser autoplay policies
- Multi-tab communication inside Chrome extensions
- High-performance animations with Framer Motion
- Structuring a scalable extension with Vite
- Balancing creativity with accessibility and performance

🎨 What’s Next for Halloween Vibes
Multi-Theme Expansion

Cute Halloween
Gothic
Cyberpunk Halloween
Retro Halloween
Seasonal Themes

🎄 Christmas

🎆 New Year

💖 Valentine’s Day

🐇 Easter

🎉 Birthday Theme

More Features

Customizable sound packs

Adjustable jump scare frequency

More decorations & animations

Theme selector inside the popup

Halloween Vibes is evolving into a year-round seasonal web transformation extension.

💡 How Kiro Helped Build This Project

Kiro played a huge role in speeding up development:

Steerings

I used detailed steering docs covering:

Accessibility guidelines

Animation rules

Architecture standards

Performance constraints

Sound design rules

This helped Kiro generate code that matched my design system, accessibility requirements, and Halloween vibe without constant correction.

Hooks

I automated:

Pre-write filename validation
Automatic file headers
Project context injection
Task planning review

This made code generation more consistent and saved a lot of time.

Specs

I kept my spec focused on the MVP first, then layered complexity later. Reviewing each task before execution made everything predictable and clean.

🔗 Built With

React

TypeScript

Vite

🎉 Try It Out

👨‍💻 GitHub Repo:
https://github.com/lucidyatra-web/halloween-vibes

Why You Need to Know How a Database Works Internally?

Deepak Singh — Sun, 14 Sep 2025 18:02:36 +0000

We rarely build our own database engine from scratch, but even then, understanding how databases work internally is important. Without this knowledge, it becomes hard to choose the right database according to business needs or tune a particular database to fit those needs.

In this article, you will gain a good understanding of the internal workings of databases without much technical jargon. By the end, you will have clear reasons to choose a particular database engine while building your next impactful software application.

Imagine This: Building the Fastest Database

Let’s say you sat in a time machine and went a few years back when databases were about to be invented. As a great software engineer from 2025, you are asked to build the fastest database. What technique would come to your mind first? Hashmaps?

Why not? They are used to read and write data in constant time (O(1)). So theoretically, they should be the best database in the world. And indeed, a similar concept was used in the beginning (like Bitcask). But if you check the 2025 statistics, you’ll find that B-Tree (which we will discuss later) is the most popular database engine for storing data, and it does not use hashmaps.

Why? Because we don’t need perfection. We need something that works and reduces cost.

Let’s go through important database engine terms, where to use each one, and their advantages over others.

Hash Index

By its name, you already understand that this technique uses hashmaps. But more important is how it is implemented for reliability, concurrency, and fault tolerance.

Hashmaps are generally in-memory data structures for maximum efficiency. I said generally because we can use disk for hashmaps too, but that wouldn’t be efficient. Disks like HDD and SSD are not designed for this type of random-access operation.

In a hash index, we maintain an in-memory hashmap whose key is the actual key of the data, and the value is the offset (or location) of that data on the disk. The value can be large, so it is not stored in memory. Only a single seek time (finding a value by address on disk) is added.

But what if the machine crashes while updating a value? The data would be in a partial state, which would be useless. To solve this, log-structured techniques are used.

An append-only file (where nothing is overwritten) stores the data. Whenever we need to update a value, we simply write the new value, and the hash index now points to this new version. However, this causes disk space to increase rapidly.

To solve this, instead of writing the whole data into a single file, we write data in segments and continuously merge them to keep only the latest value for each key (known as compaction). This happens in the background so that read and write operations are not affected.

Limitations of Hash Index:

On machine restart, all keys are lost. This is solved by taking periodic snapshots of the keys and storing them on disk.
RAM is expensive and limited in size, so we can’t store many keys, and several disk management techniques can’t be applied.
Although we can access any key-value pair in O(1), range queries (retrieving data between a particular range) cannot be efficiently performed with hashmaps. And range queries are crucial in most businesses.

SSTables and LSM-Trees

Now we encounter some names that seem technically complex but aren’t.

What is an SSTable?

An SSTable (Sorted Strings Table) is a file format where strings (keys) are stored in sorted order. That’s it.

The idea is to improve upon the hash index.

We know that in a hash index, data is stored in segments. In the same way, here too, data is stored in segments, but each segment is in SSTable format — sorted by keys.

Each SSTable has its own in-memory or disk-based hash index. That is, a table we can use to get a key’s value from that segment.

Better alternatives than hash tables also exist — not necessarily faster, but they work fairly well while reducing cost. For example:

Sparse tables with binary search
Other efficient lookup structures

Because segments aren’t very large, these work great.

Compaction happens here too, but in a slightly better way. A merge sort is used so that the new segment appears in sorted order.

But where do SSTables come from?

Because we write data in any order, we use an in-memory AVL or Red-Black tree. This tree stores incoming data in sorted order. After crossing a threshold, the data is flushed to disk in SSTable format, and memory becomes reusable.

This helps in writing data more than the available memory and enables range queries because of the sorted keys.

This entire technique is known as LSM Tree (Log-Structured Merge Tree). Easy peasy, right?

To read data:

First, we look in the in-memory tree (called the memtable).
Then, in the latest segment.
Then, in older segments sequentially.

If data is very old or not present, we might have to look into too many segments, which is inefficient. To solve this, Bloom filters are used to quickly check if a key exists in a segment.

Limitations of LSM Tree:

Even though we use Bloom filters, reads are not very fast.
This makes LSM Trees less suitable for read-heavy applications.

B-Tree

Don’t confuse it with a Binary Tree or Binary Search Tree — it is completely different.

B-Tree is the most popular data engine, used by big names like MySQL, PostgreSQL, and Oracle. Why?

Because of its balanced performance in read and write operations, especially for disk-based databases.

How does B-Tree work?

A B-Tree stores several pages of fixed-size blocks.
Each page holds keys in sorted order and references to other pages.
References are not random. Each reference between two keys points to pages containing keys in that range.
Leaf pages contain references to values or the values themselves.

It looks like a search tree but differs in how data is inserted.

Any key-value pair is inserted into the appropriate leaf page.

If a page doesn’t have space for a new key:

It splits into two equal parts.
The parent page adds a new reference to the extra page.
This process continues up to the root.
If the root splits, a new root is created.

Although it seems like heavy work, in practice, 4–5 levels contain a lot of data.

Read and write complexity remains O(log n).

Limitations of B-Tree:

In concurrent scenarios or server failures, a B-Tree can become corrupted due to missing parent references.
This is solved by Write-Ahead Logging (WAL) — an append-only file written before the actual B-Tree modification.
However, WAL makes B-Tree slower in writes.

Summary: Choosing the Right DB Engine

We covered the most popular DB engines and their internal workings.

B-Tree is the most mature and optimized engine, making it a widely popular choice.
All techniques are useful and chosen based on specific business needs.

It’s impossible to directly compare them due to factors like:

Data type and complexity
Workload type
Database tuning

But generally:

In the end, the choice is not about the fastest or best, but the one that suits your software application the most.

Consider your business needs carefully and tune your DB engine accordingly.

Thank you for reading!

Feel free to comment your thoughts or share how you chose your database in your last project.

References

Kleppmann, M. (2017). Designing Data-Intensive Applications: The big ideas behind reliable, scalable, and maintainable systems. O’Reilly Media.

Which Database Should We Use: Relational, Document, or Graph Model?

Deepak Singh — Fri, 05 Sep 2025 03:32:15 +0000

A good general answer is: everything. In real-world applications, using a mix of all types of database models is often the most efficient approach.

So the better question isn’t “Which database should we use?” but rather: “Where should we use each type of database model?”

Even if using all data models isn’t feasible for a business, this article will give you a deeper understanding of how different database models work — and how we can even simulate multiple models within a single database type. This might seem hacky, but modern applications’ need for polyglot persistence has pushed databases to provide functionalities beyond their original model.

Understanding Basic Terminology

Before diving deeper, let’s clarify some key concepts.

Data Model

A data model is a way of storing data. It can exist at different levels: hardware, software, or application layer. Each is complex in its own right, so abstraction is crucial.

For example, if you want to store user resume details, you don’t need to worry about how it’s stored at the electrical current level. Instead, we focus on application layer data models, which describe how data is structured and accessed, not how it’s physically retrieved.

Types of Relationships

Entities in real-world applications are often related in different ways. Understanding the type of relationship is essential for choosing the right database model.

Many-to-Many: One entity can relate to many others, and vice versa.

Example: A case can have many tests, and a test can belong to many cases.
One-to-Many: One entity can have many of another entity.

Example: A person can have multiple education entries. Note that the reverse may not hold true.
Many-to-One: Many entities relate to a single entity.

Example: Many users can work in the same industry, but one industry doesn’t have the same user multiple times.

With these concepts clear, understanding the role of each database model becomes simpler.

Why Different Data Models Exist

Data Locality

Data that is related and often read together should be stored together. This is called data locality.

Relational Database

Relational databases (RDBMS) are the classic approach. Many of us first encounter databases through relational tables — whether in IT or simple real-world analogies like notebook tables.

Though RDBMS feels old-fashioned, they became powerful with query languages like SQL, which allow efficient data manipulation, retrieval, and JOIN operations. Relational databases were specifically designed to optimize referenced data retrieval — technically, this is what a JOIN does.

Document Model

Document databases feel very natural to developers because they store data in objects or JSON-like structures, which reduces impedance with applications.

The main advantage of document databases is data locality — related information is stored together, making reads more efficient.

Example: Netflix can store all movies a user likes in a single document for easy retrieval.

Flexible schema design also makes document databases ideal when the data structure isn’t fixed.

Graph Model

Graph databases store data as vertices (entities) and edges (relationships). The vertices can be heterogeneous, such as users, posts, comments, or likes.

Graph databases shine in handling complex many-to-many relationships, such as social networks (Facebook, LinkedIn), where the relationships themselves are critical.

Choosing the Right Data Model

One-to-Many Relationships: Document databases work well because related data can be stored together. However, if the “many” side is independent or highly nested, a relational table with references may be better.
Many-to-One Relationships: Storing the “one” side as a reference prevents data duplication, making relational databases suitable.
Many-to-Many Relationships: These often require join tables in relational databases. For more complex relationships, graph databases are optimal.

Polyglot Persistence: Simulating Other Models

In real-world applications, relationships are usually a mix of all types. Modern databases help handle this complexity:

MongoDB supports lookups, a form of joins.
Relational databases now support JSON storage and manipulation.

Even as applications scale, some data remains unstructured, rapid, or requires locality (IoT, logs), so document models remain relevant.

Conclusion

The key takeaway isn’t just which database to use, but when to use each data model. A successful design balances relational, document, and graph models to best fit the application’s needs.

References

Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O’Reilly Media.

OOP Didn’t Invent Anything New — It Just Gave Us Discipline

Deepak Singh — Sun, 31 Aug 2025 07:25:13 +0000

Deepak Singh

3 min read · 13 hours ago

Encapsulation, inheritance, polymorphism — we had them long before OOP.

What OOP really did was add discipline, structure, and accessibility.

And that’s exactly why it changed everything.

The Big Misconception

When people talk about Object-Oriented Programming (OOP), they often ask:

“But didn’t OOP give us encapsulation, inheritance, and polymorphism?”

The truth: No, it didn’t.

All three concepts existed before OOP.

What OOP brought was a way to enforce constraints and discipline around how we use them.

Surprisingly, that’s what made OOP revolutionary.

Let’s break it down.

Encapsulation

Encapsulation means hiding data and exposing behavior through controlled interfaces.

But hiding from whom? And why?

Encapsulation in C

Long before OOP, C programmers used header files (.h) and implementation files (.c) to achieve encapsulation.

// mathlib.h
#ifndef MATHLIB_H
#define MATHLIB_H

int add(int a, int b);
#endif

// mathlib.c
#include "mathlib.h"

int add(int a, int b) {
    return a + b;
}

// main.c
#include <stdio.h>
#include "mathlib.h"

int main() {
    printf("%d\n", add(3, 4)); // Output: 7
    return 0;
}

Here, the caller knows a function exists but not how it works.

The same applies to structs: we can declare them without exposing internals, forcing access through functions.

This abstraction might feel like “hiding a book from ourselves” — but it’s intentional.

By forcing ourselves to interact through controlled functions, we reduce coupling and make future changes safe.

What OOP Added

OOP gave us keywords like private, protected, and public.

class Account {
private:
    double balance; // hidden
public:
    void deposit(double amount) { balance += amount; }
    double getBalance() { return balance; }
};

This made encapsulation easier to apply in a single file, even though compilers still know about structure layouts.

So, OOP didn’t invent encapsulation — it just made it mainstream and practical.

Inheritance

Inheritance means reusing code by deriving one type from another.

But guess what? Programmers were already doing it in C.

Inheritance in C

typedef struct {
    int x;
    int y;
} Point;

typedef struct {
    Point base;   // reuse Point
    char name[50];
} NamedPoint;

By embedding one struct inside another, C developers could simulate inheritance.

But it only worked for single inheritance, and managing it got messy.

What OOP Added

class Point {
public:
    int x, y;
};

class NamedPoint : public Point {
public:
    std::string name;
};

OOP gave us first-class syntax.

Clean, readable, and no casting tricks required.

So again, inheritance wasn’t new.

OOP just made it simple and expressive.

Polymorphism

Polymorphism means the same function name can behave differently depending on context.

In OOP

class Shape {
public:
    virtual void draw() = 0;
};

class Circle : public Shape {
public:
    void draw() override { std::cout << "Drawing Circle\n"; }
};
class Square : public Shape {
public:
    void draw() override { std::cout << "Drawing Square\n"; }
};

Different objects (like Circle or Square) can implement the same function (e.g., draw) in different ways.

Polymorphism in C

Before OOP, C programmers used function pointers to achieve polymorphism.

#include <stdio.h>

typedef struct {
    void (*read)();
} Device;
void readFromConsole() { printf("Reading from console\n"); }
void readFromFile()    { printf("Reading from file\n"); }
int main() {
    Device console = { readFromConsole };
    Device file = { readFromFile };
    console.read(); // Reading from console
    file.read();    // Reading from file
}

That worked, but it was clunky and risky.

OOP gave us a safer and cleaner way.

Why Polymorphism Changed Everything

Among the three pillars, polymorphism was the game-changer.

Imagine plugging a new device into your PC.

Without polymorphism, you’d need to rewrite functions for each new device.

With polymorphism, as long as the device implements the same interface, your existing code just works.

Even more importantly, polymorphism enables Dependency Inversion.

Higher-level code no longer depends on low-level details.

Instead, both depend on shared contracts (interfaces).

This makes systems:

More maintainable
Easier to extend
Loosely coupled

That’s real power.

Final Thoughts

OOP didn’t invent encapsulation, inheritance, or polymorphism.

Those ideas existed long before.

But OOP gave us discipline, structure, and accessibility — making these ideas practical for everyday programming.

And that’s the real lesson:

Building great software isn’t always about inventing something new.

Sometimes, it’s about applying the right constraints to create powerful systems.

References

Martin, R. C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall.

Why Programming is Science Rather Than Maths

Deepak Singh — Mon, 18 Aug 2025 17:49:18 +0000

"Testing shows the presence, not the absence, of bugs." — Edsger Wybe Dijkstra

If I ask you whether programming is fundamentally science or mathematics, many people would say mathematics. It feels like it — we use variables, functions, operators, and assignments, which all look like math.

But if we go down to history, we'll see that programming started as a vision to make it mathematical — and then, fortunately or unfortunately (you decide), it transformed into a science.

Maybe this is why we study Computer Science and not Computer Mathematics.

The real question is: Why?

Why is programming a science and not maths?

And could programming have been better if it had stayed mathematical?

You may not get the answer to all of these questions in this article — some are still a "black hole" for us. But you'll understand why structured programming, the backbone of modern software engineering, leans on science instead of math.

The Beginning: Programming with Punch Cards

In the early days, programming was done on punch cards. People at that time had no idea about the future of programming — they were simply trying to reduce the complexity of mathematical calculations.

Edsger Wybe Dijkstra lived in this era. A brilliant mind, he excelled in mathematics, physics, chemistry, and biology during high school. He later became one of the very first programmers, working with large computers, punch cards, and then core-level assembly languages.

The problem of that time? Programs were monolithic and tightly coupled.

A single error could break the entire application, and even a small change in the problem meant rewriting huge amounts of code.

Dijkstra's Vision: Programming as Mathematics

Dijkstra wanted programming to be like mathematics, where we rely on already-proven lemmas, theorems, and corollaries.

In mathematics, proofs build on previous truths:

We don't re-prove the basics every time.
Lemmas (already true statements) help prove theorems.
This recursive building of truths leads to powerful results like integration, differentiation, gradient descent, backpropagation, and more.

Dijkstra's vision was to prove fundamental algorithms, which would then serve as theorems, making larger algorithms provable more easily.

The Roadblock: GOTO

In mathematics:

Sequential statements can be proved by enumeration.
Iterations can be proved using mathematical induction.

But programming in those early days used GOTO — an instruction that transfers control anywhere in the program. This broke the possibility of enumeration and induction-based proofs.

The solution was to restrict GOTO. That's how if/else, loops, and breaks were born — controlled ways of transferring control.

This was a breakthrough. It gave us the ability to write modular, independent blocks of code instead of monolithic programs.

But… the proofs never came.

Where Science Entered

Even though Dijkstra's mathematical proofs never materialized, his ideas weren't wasted. The removal of GOTO gave us structured programming — and with it, a way to build modular, testable code.

Here's where science took over:

In mathematics, we prove something to be true forever.
In science, we don't prove truth — we prove falsehood.
If after countless experiments we can't disprove a theory, we accept it as true (for now).

For example: Newton's law of gravitation

was accepted until Einstein's relativity disproved it.

Programming works the same way:

We test submodules with unit tests.
If a test fails, we fix the module.
If it passes thousands of tests, we assume it works.
Then we combine modules and test again at a higher level.

This is science at work: truth until falsified.

The Conclusion

Fundamentally, programming is science, not mathematics.

Dijkstra's vision of mathematical programming never fully came true. We don't know if it would have been better — maybe, maybe not.

But what we do know is this:

Programming behaves like science.
We test, disprove, and iterate.
We can't prove code to be true for all cases, only that it hasn't failed yet.

And that's why we say:

Programming is science. It is true… until we find a bug.

References

Martin, R. C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall.

Do You Have a Good Software System? Of Course, Yes!

Deepak Singh — Sun, 10 Aug 2025 16:53:21 +0000

Do You Have a Good Software System? Of Course, Yes! Everyone will say that — until they get a failure that makes them lose millions.

Before building a good software system, we have to know what really is a good software system. What are the measures of a good software system?

After this article, you will get to know what is a good software system and why it is important. Or maybe I’ll tell you right now why it is important in short — yes, money. Money is the why.

With a good system, your application will be alive most of the time, in most situations, and for a longer time — meaning more money will flow through your accounts.

Why Things Get Complicated

Before diving into all these measures, we have to go through data systems — why things get complicated even when we have amazing modern tools to work with. We have tools for everything: servers, databases, frontend technologies, and more.

When a user is interacting with data stored in a DB, it’s not just like a direct operation on data like we do on our local system. Even in a simple system, there are multiple tools working together like caching tools, indexing tools, or message queues. All these work together to give the end user a fast and efficient response.

Example:

This is the data system where data is traveling through several tools, and we have to take care of every part of the tool. For example, if the name of a user is changed in the DB, it should also reflect in the cache memory.

And look here — for every part like caching, DB, and indexing, we are doing them separately. Even if a modern DB can provide caching, it is not as effective as caching as a separate tool. So, in any software system, a lot of tools are involved in the data system, which makes it complicated and has to be handled properly.

Measures of a Good Software System

1. Reliability

Most people are aware of a part of it and work on it most of the time. Reliability means the system works according to the requirements of the user. But not only this — the system should work even if some level of faults occur in components of the system, users send unreliable data to the DB, or the user should not be able to get unauthorized data.

The system should be fault-tolerant, meaning it should work in case of different kinds of faults:

Hardware faults: Hardware faults like system crashes, electricity going down, hard disk failures, and more. Physical devices are prone to faults and even have some lifespan after which they stop working. To handle this, we use things like RAID configurations, dual power supplies, and diesel supply in emergencies.
Software faults: Software can sometimes behave unpredictably due to several conditions like heavy CPU or data workload, defective data, legacy software, platform dependency, and others. If one component is affected, others should still work — meaning less coupling in the system.
Human faults: Mistakes are part of humans, and we can’t separate them from us. Human faults are always there in any software system, but they should not make the system stop working. While working, a separate sandbox should be provided to engineers with separate data to reduce risks.

2. Scalability

If the system is reliable at the current load, it doesn’t mean it will work at 10x the data load. We must make the system handle more data according to the growth of the application. Growth is always unpredictable, so ignoring scalability is risky (though in the case of an MVP, we can skip it).

We first need load parameters that define how load will increase. It may seem simple to just increase the number of user requests, but in most cases, it’s not.

Example: Twitter (2012 data)

Post Tweet: 4.6k requests/sec on average, over 12k/sec at peak.
Home Timeline: 300k requests/sec.

Two approaches:

A global DB with all tweets, all writes done here, and the feed fetched by matching followers in the DB.
Each user has their own cache with tweets from only their followers — reducing read complexity but increasing writes.

Twitter switched from the first to the second method for scalability. Now, followers per user became a critical load parameter. If someone has 30 million followers, write operations increase very rapidly.

When testing scalability, response time is key — but average response time is not a good metric. It hides slow requests. Amazon, for example, may have an average of 200ms, but its slowest 5% requests could be over 1 second — possibly from its most valuable users.

Percentiles like p50, p95, p99, and p999 are better metrics. They tell exactly how many requests are slower. But if improving extreme percentiles costs too much, avoid it.

Also, slow requests can block faster ones because of limited CPU or DB parallelism. In request chains, the probability of hitting the slowest request increases, making the whole chain slow.

3. Maintainability

At the start of building a software system, we focus on meeting requirements and implementing features. Over time, as the application grows, every new change requires going through older databases and code — which must be clean and organized to avoid productivity loss.

Key maintainability practices:

Avoid redundant complexity that doesn’t solve user problems.
Use abstraction to reduce coupling.
Keep monitoring systems active.
Practice Test-Driven Development (TDD).

Conclusion

Now you understand how to know if a system is a good software system. Go let your business boom in the market — and don’t let technology leave you behind. These metrics measure the goodness of a software system regardless of the language, tool, or framework you use.

Now whenever someone asks — "Do you have a good software system?" You can say: Of course, YES!

References

Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O’Reilly Media.

Software Success: Balancing Architecture and Behavior

Deepak Singh — Sat, 09 Aug 2025 14:52:28 +0000

Software Success: Balancing Architecture and Behavior

“Your software’s behaviour can win clients today — but only its architecture will keep it alive tomorrow.”

What are the two important things a software is expected to do?

Well, everyone knows the first one — behaviour — meaning it should behave according to requirements. Easy-pissy.

But what is the other important thing? Software architecture — meaning how components of the software are arranged.

But is it really important?

What if I tell you it has the same value as behaviour, or maybe more, but not less for sure?

In this article, my sole purpose is to make you understand the value of architecture in such a way that your hands will get stuck on the keyboard if you do not care about architecture while building software.

1. Behaviour

You, your client, your manager, your development team — all of these understand what behaviour is because this is the thing you will present to the client or users.

You first develop the requirement document and then code the software so that it behaves according to that document. All the upcoming features and bugs are part of the behaviour of the software.

2. Architecture

It is how our software is arranged. Sometimes, managers don’t even know what it is, and a manager will prioritise it lower (if not a good manager) until he comes up with actual data — yes, data — which will reveal how much loss the company is making because of poor architecture.

The Data That Proves It

This shows the number of employees in 8 versions of a software:

And this is the productivity per release of the software:

It kept decreasing, and at a point, it will become 0.

Zero productivity — man, just think — it means you will not be able to change the software according to future requirements. Then what’s the purpose of the software anymore?

Okay, first you might think that it is impossible that we can’t change the software anymore, right?

But if its cost is so high that it makes you losses, then you don’t change it. This is what I mean by zero productivity.

Why It Happens

So why did it happen even with the increasing number of people per release?

Well, if the architecture of the software is so bad, then when you have to change something in it, you don’t understand where to start and how many files to change.

It becomes riskier, harder, and takes more time, which costs more to the company.

But with good architecture, even an intern can add a new functionality because he doesn’t have to focus on the coding hell — only on meeting the requirements.

A Great Experiment by Jason Gorman

This will make most people believe everything written here. Jason conducted this test over a period of six days.

Each day, he completed a simple program to convert integers into Roman numerals. He knew his work was complete when his predefined set of acceptance tests passed.

Each day, the task took a little less than 30 minutes.

Jason used a well-known cleanliness discipline named Test-Driven Development (TDD) on the first, third, and fifth days.

On the other three days, he wrote the code without that discipline.

And here are the results:

You can clearly see that when done with good architecture practices, the work is completed way faster.

And this is the data we have to rely on — not our intuitive decisions.

Final Thoughts

We all think we have to finish the behaviour and can focus on architecture later — but no, there is no time for us to do it later.

With each bad architecture, software becomes less flexible to change and performance decreases.

The conclusion of this article is that architecture has the same or more value than the behaviour of the software.

If we want to make software live longer, then a good architecture should be chosen, and we must be consistent with it.

But behaviour is also an important aspect, as we all know, so choosing a good balance and setting priorities is important.

That’s it for this article. I will keep showing up with future articles about Clean Architecture as well as other important engineering concepts like system design, databases, and problem solving — the real things that are needed.