DEV Community: cartmann68

The cost of simplicity

cartmann68 — Wed, 02 Sep 2026 06:29:28 +0000

The simplest solution is usually best only while the problem itself is simple.

This simple statement is often overlooked in software engineering. Many developers are drawn to the idea of simplicity, but they fail to recognize that simplicity is not an absolute quality. It is relative to the complexity of the problem being solved.The recurring argument that sounds sensible at first is — why complicate things, is only valid when the problem itself is genuinely simple. When the problem is complex, refusing to acknowledge that complexity does not make it disappear. It merely forces that complexity to reappear somewhere else, often in a much uglier form.

Why use TypeScript and React when simple HTML and JavaScript already works? Why use Next.js when plain direct DOM APIs are enough? In operating system design, the same question could be asked about virtual memory and page tables. Why introduce all the machinery of address translation, TLBs, and page faults when the CPU could simply access physical RAM directly?

That instinct is not foolish in and of itself. In fact, it is often correct. If the problem is genuinely small, the simplest solution is usually the best one. A tiny static website does not need a large application framework. A small embedded system running one fixed program may not need virtual memory. A shed does not need the structural systems of a skyscraper. The mistake begins when we take something that works beautifully at small scale and assume that it must therefore remain the best solution at large scale.

Imagine a man who has built a wooden shed in his backyard. He needed some lumber, nails, a roof, a door, and perhaps a window. The whole thing could fit on a simple sketch. There are no elevators, no fire-suppression systems, no reinforced concrete core, no emergency stairwells, no backup generators, no ventilation shafts, no structural calculations for wind loads hundreds of feet above the ground. Now imagine that same man standing beside his shed and pointing toward a skyscraper in the distance. He shakes his head and says, “Look at all that unnecessary complexity. Pumps, elevators, steel reinforcement, control systems, fire doors, electrical rooms, emergency exits, drainage, backup power. I built my shed without any of that.” Everything he says about his shed is true. His conclusion is still absurd.

The skyscraper is not complicated because its engineers enjoy complication. It is complicated because eighty floors of people create problems that a shed never has to solve. The requirements themselves have changed. Once hundreds or thousands of people must safely live or work inside the same structure, entirely new problems appear: vertical transportation, fire evacuation, water pressure, structural movement, power distribution, ventilation, sewage, communication, and redundancy. The complexity did not originate in the architect's imagination — it came from reality.

Software works the same way. A simple website may be created with little abstraction and very few dependencies. But a serious, large-scale enterprise web application requires much more. It has to handle authentication, responsive data loading, caching, error handling, client-side routing, internationalization, smooth transitions and animations, modern UI/UX practices, loading and error states without a full page refresh, route middleware, granular access controls, complex business logic and a host of other concerns. The requirements themselves have changed. The complexity came from the client's requirements.

While a simple embedded system might be fine with direct memory access and a flat RAM structure. The simplest possible memory model is wonderfully direct. The CPU has an address, and that address refers to a physical location in RAM. If the processor requests address 42,000, the machine reads the byte stored at physical address 42,000. For a tiny computer running one fixed program, this is elegant. There is almost nothing between the program and the hardware. However, a serious operating system has to manage hundreds of processes running at the same time, protect their memory from each other, allow programs to grow in memory dynamically, two programs may want to share the same library, files should be mapped directly into memory, you want to give programs contiguous memory, manage memory fragmentation, consider performance, security and deal with hardware quirks all at the same time. At this scale a direct memory model is no longer optima and would introduce more complexity than using a virtual memory model with page tables, TLBs and address translation. Again, the complexity has come from the requirements of the system. Paging did not invent the need for isolation, sharing, dynamic growth, fragmented physical memory, or memory-mapped files. Those problems existed because modern computers were expected to do more. Paging gathered many of those problems into one coherent abstraction.

Rocket science is not complicated because rocket scientists want to be clever. It is complicated because the requirements of spaceflight are complicated. A rocket must survive extreme acceleration, vibration, and temperature changes. It must carry enough fuel to reach orbit while being light enough to lift off the ground. It must be aerodynamically stable while being structurally sound. It must be able to communicate with ground control while protecting its electronics from radiation. The complexity has come from the physics itself.

This is a recurring pattern in engineering: a mechanism may become more complicated locally in order to make the entire system simpler globally. The important question is whether the primitive tool still produces the simplest overall system once the problem is no longer primitive. If the requirements themselves are complicated, refusing architecture does not make the complexity disappear. It merely forces that complexity to reappear somewhere else, usually in a much uglier form: duplicated code, global state, special cases, scattered event handlers, undocumented conventions, fragile assumptions, and enormous chains of conditionals.

Much of civilization itself is built this way. We live on top of layers of systems that allow us to interact with enormous complexity through simple interfaces. At small scale, informal systems are often superior because formal structure would cost more than it provides. At large scale, the absence of structure becomes dangerous. Genuine complexity has to live somewhere. If the requirements are complicated, we cannot remove that complexity simply by refusing to acknowledge it. We can place it in abstractions, frameworks, type systems, schemas, hardware, documentation, institutions, conventions, or procedures. Or we can leave it scattered across people's memories, hidden assumptions, duplicated logic, manual work, and special cases. But it will live somewhere. Rejecting visible complexity often creates invisible complexity, and invisible complexity is usually more dangerous because nobody can clearly see where the rules are. The goal of engineering, then, is not simply to “make everything simple.” That advice is too shallow. Nor is the goal to use the most sophisticated tools available. The goal is to build the least complicated system that can reliably contain the actual complexity of the problem.

Who should decide UI?

cartmann68 — Wed, 03 Dec 2025 09:43:35 +0000

What do you do as a product manager when your design team push for a clean, modern interface, while developers argue for the old, familiar UI?

tldr;

You should always go with the solution of the designers because they are designing for users not programmers.

1. Programmers are not the audience.

Developers spend their life inside complex tools, terminals, logs, IDEs — clutter doesn’t bother them because they’re trained to survive it. But users are not developers. Normal people don’t want interfaces that look like a cockpit from the 1990s.

2. Designers are literally trained to solve this problem.

A designer’s whole job is:

visual hierarchy
readability
spacing
usability
clarity
human factors

A programmer’s job is not design. Their taste is shaped by tools built for power-users.

3. Old, cluttered interfaces only feel “better” to developers because they expose internal structure.

Developers like seeing everything at once because it mirrors how they think: data → structure → options → panels → nested menus. Users, on the other hand, get overwhelmed and leave.

4. Modern UI isn’t “minimalism for the sake of minimalism.”

Good modern design reduces friction. Not fewer features — fewer obstacles. Clearer choices. Better flow. Safer defaults.

5. Every successful product on earth follows the designer, not the engineer

Apple, Google, Stripe, Figma etc. all prefer a clean and modern UI. If “cluttered 1990s UI” were better for users, the entire industry wouldn’t have abandoned it.

6. **Engineers usually change their mind once they use the cleaner version**

At first they complain because everything moved. A week later they admit the new design feels calmer, faster, easier to navigate.

7. The business side also points in one direction

Clean modern UI =

lower support tickets
higher conversion
higher user trust
easier onboarding
better perceived quality

Clunky UI = “This looks old, I don’t trust it.”

Conclusion

Design for users, not for developers.
Follow the clean, modern design.
Developers can adapt — users won’t.

If you want harmony between teams, the compromise is this:

UI = clean, modern
Advanced settings = tucked away so power-users can still access them
Internal developer tools can be as ugly and cramped as programmers enjoy

Customer-facing products should be modern and clean.

🔥

cartmann68 — Wed, 03 Dec 2025 09:30:46 +0000

Why JavaScript Is the Best Programming Language in the World

Neo Hacker ・ Aug 29

#webdev #javascript #react #programming

Why you need event-driven architecture

cartmann68 — Wed, 03 Dec 2025 09:25:49 +0000

Events are often used to decouple logic and keep a system modular.

Events allow for a very modular architecture. Your system emits events at different points in time and this allows you to create a completely independent and pluggable module which hooks into these events without needing to make any changes to the core part of your system. For example, you might create a Notification module which listens to various events in your system and sends e-mail, text messages, push notifications and performs other actions related to notifying your users. All of this without ever needing to change any part of your existing codebase. Your module can have a single responsibility, be completely self-contained and independent.

For example, POS systems often have a local law requiring them to implement the payment system as a completely separate module. Without events and hooks this becomes impossible. You look at the code and see that everything depends on everything, the payment system is intermingled with every other part of the system. You throw your arms up in the air and say, no way, this can't be done. Payments are the very core of a POS system. It runs through everything. But that is just a sign of a badly architected system. It doesn't need to be this way. Everything should not depend on everything. That's a brittle system. With an event-driven, modular architecture you simply emit events and let the payment module hook into these events and handle the logic.

Think of a radio broadcast (emitting events). The broadcaster simply broadcasts into the air. Anyone who wants to and has a radio (listener) tuned to the frequency hears the message. The broadcaster doesn’t know or care who’s listening.

Why abstractions are good

cartmann68 — Wed, 03 Dec 2025 09:18:50 +0000

Have you noticed how our world is built on abstractions? Abstractions are everywhere. We have abstractions in code - one library depends on another library which depends on another and so on. But it's not just code. We use abstractions every day. Every time you plug something into a wall outlet - you are using an abstraction, a huge electrical infrastructure with its own abstractions, completely invisible and hidden from you. When you drive your car, you don't operate with gears and wires, instead you turn a key, push a button, turn the steering wheel. You don't care how it works - you don't even want to know how it works. You're using abstractions to get where you need to go.

A World without abstractions and dependencies

Imagine a world without abstractions. Let's say you wanted to build a house. You'd need tools and materials but if you couldn't rely on abstractions and depend on the work of others, you would need to create all the tools and materials yourself. Just think of how much work goes into making something as simple as cement. You need limestone, clay, sand, and gypsum. But in order to get those things you need quarries, explosives, heavy machinery, fuel, trained operators, safety systems, transportation. And each of those depends on even more things. It's almost an infinite chain of dependencies.

If you were building a house without using any dependencies, you'd need to create your own tools. Think of how many things are involved in making a power drill - motor, a chuck, a trigger, a shell. A motor needs magnets. Those magnets alone require an entire industry: mining rare earth metals, crushing ore, separating the elements through complex chemical processes, sintering them at high temperatures, machining them, coating them so they don’t corrode.

In software development, a function relies on a library, that library relies on other libraries, all of it runs inside an environment, which depends on system libraries, which itself sits on top of an operating system, which depends on hardware, which ultimately depends on silicon and the physical world underneath it.

The real world depends on abstractions, an almost infinite supply chain of dependencies. And that’s the whole point: none of us could ever build anything meaningful alone. We stand on top of the work of millions of people we’ll never meet, quietly building layer after layer so the world feels simple on the surface. Abstractions are what let us make progress. They let us create without having to reinvent the entire universe first.

Once you see that, you start appreciating the hidden scaffolding underneath everything — and you realize how impossible life would be without it.

What DRY actually means

cartmann68 — Wed, 03 Dec 2025 09:16:26 +0000

A lot of junior developers misunderstand DRY (Don't Repeat Yourself) as a strict rule against any code duplication. To them DRY means:

never repeat a line of code
never have two components share similar structure
never write anything twice

If something looks similar, they feel obligated to merge it, abstract it, or build a “super component” with flags and conditions. Of course, the result is always the same: Overcomplicated, brittle, unreadable code that was technically DRY — and practically unusable..

Pizza Recipes

Imagine if a cookbook tried to follow the the DRY principle to the extreme. Instead of having separate recipes for different types of pizza, it would try to create one giant single pizza recipe that covers every possible variation - one "single universal pizza recipe".

“Use tomato sauce unless you’re making quattro formaggi — in that case, ignore this and jump to the cheese section.
Add pineapple only if not using anchovies or mushrooms. If using both, skip pineapple and go to page 245, see section b.
If using olives, skip basil unless also adding mushrooms…, in that case turn to page 658”

Technically DRY — only one pizza recipe. But completely unusable. In real life, we keep multiple recipes, even if some steps repeat. And that’s correct. Repetition of harmless steps is not a problem. Confusing everything into one monstrosity is a problem. It's perfectly fine to have every pizza recipe start with "Take the dough and roll it out." because clarity is more important than eliminating every repeated line.

IKEA Furniture Manuals

Imagine if IKEA tried to be DRY by shipping one giant instruction manual for all their furniture instead of separate manuals for each product.

“If assembling a chair, skip to page 573.
If your item uses bolt type B2, follow section 19.
If you’re building something with drawers, go to section 1447 unless it’s the office series…”

That would be completely insane and unusable. Instead, IKEA provides individual manuals for each product, even if many steps repeat across manuals. Because clarity is more important than eliminating every repeated step.

The same principle applies to code. You don't search the codebase for every instance of "class extends Model" to merge them into one mega-class. You create many small, focused classes that are easy to understand and maintain.

The DRY principle is about avoiding duplication of knowledge, not avoiding duplication of keystrokes.

Duplicating logic is bad.
Duplicating meaning is bad.
Duplicating rules is bad.

It's not about trying to avoid duplicating structure. It is often the healthy, maintainable thing to do. Don't try to eliminate every repeated line of code by merging unrelated logic, stuffing everything into one mega-component, making endless if-statements, adding flags or creating abstractions nobody understands. That only produces coupled, brittle, unreadable code that is dangerous to change. This is not what DRY means.

True DRY is about removing duplication of concepts and rules, like centralizing email validation, having one shared price-calculation function, using a composable that handles quantity logic, or extracting truly shared behavior. This produces code that is clear, testable, easy to maintain, and respects boundaries.

Remember, we don't have one huge pizza recipe or one giant IKEA manual. Nobody wants that.