Glossary of Software Engineering Logic
// The Engineering Vocabulary: Beyond the Syntax
In a world obsessed with framework updates and speed to market, weve lost the common language of logic. Most developers can describe how a for-loop works in five different languages, but few can articulate why their system is collapsing under its own cognitive load.
This Glossary isnt a dictionary of academic definitions. Its a curated map of the obstacles and leverage points we encounter in real-world production. Weve stripped away the corporate fluff to give you the raw, unfiltered meaning behind the terms that actually define whether your project survives its first year of scaling. This is the language of Krun—where logic the only asset that doesnt depreciate.
Essential Terms & Patterns
1. Primitive Obsession
Using basic data types (strings, integers) to represent complex domain concepts. A classic anti-pattern that leads to logic leaks. We replace it with Value Objects to ensure domain integrity.
2. Cognitive Load in Code
The mental effort required for a human to process a codebase. High cognitive load is the primary cause of bugs in legacy systems. Our goal is to minimize it through logical transparency.
3. Technical Debt Management
The accumulated cost of choosing fast over right. We dont just identify debt; we calculate the interest rate prioritize refactoring based on business risk.
4. Architectural Subtraction
The engineering practice improving a system by removing redundant layers, features, and abstractions. Simplicity is an acquired skill.
5. Separation of Concerns (SoC)
A design principle for separating a computer program into distinct sections, such that each section addresses a separate concern (e.g., Business Logic vs. Database I/O).
6. Refactoring Legacy Code Patterns
Specific techniques for transforming spaghetti code into maintainable structures without breaking production stability.
7. Code Maintainability Metrics
The ease with which a software system can be modified to correct faults or improve performance. If code isnt maintainable, its a liability, not an asset.
8. Boilerplate Reduction
Techniques for eliminating repetitive code that provides no business value. Excessive boilerplate hides the actual logic of the application.
9. Side Effects Management
Unintended changes in state that occur outside the local scope of a function. We advocate for pure functions to make systems predictable.
10. Scalable System Design Blueprints
Pre-designed architectural patterns that allow systems to handle growth—ranging from database sharding to asynchronous messaging.
11. Production-Ready Logic
Code that accounts for unhappy paths: error handling, logging, timeouts, and circuit breakers. Its what separates a script from a professional product.
12. Domain-Driven Design (DDD) Logic
An approach to software development that bridges the gap between complex business requirements and technical implementation.
13. High-Entropy Codebase
A system that has become disorganized and fragile over time due to constant quick fixes without a coherent architectural vision.
14. Decoupling Architecture
The process of reducing dependencies between system components. Decoupled systems are easier to test, deploy, and scale.
15. Defensive Programming Workflow
A mindset where you write code expecting inputs to be malicious or malformed. Its the art of building bulletproof logic.
16. Implementation Trade-offs
The inevitable compromise between speed, cost, and quality. Engineering is the science of choosing which trade-off hurts the least.
17. Stateful vs Stateless Services
The logical distinction between services that store user data and those that process requests in isolation. Crucial for horizontal scaling.
18. Dead Code Elimination
The systematic removal of functions, variables, and modules that are no longer executed. Every line of dead code is a potential bug hiding place.
19. Encapsulation Leaks
When the internal details of a module are exposed to the outside world, creating tight coupling and fragile architectures.
20. Idempotency in API Design
Ensuring that making the same request multiple times has the same effect as making it once. Essential for reliable distributed systems.
21. Big Ball of Mud
A software system that lacks a perceivable architecture. We provide the tools to dismantle the mud and restore logical order.
22. Atomic Operations
Operations that either fully complete or dont happen at all. A core concept for maintaining data integrity in high-load backends.
23. Code Smell Detection
The ability to identify patterns that indicate deeper problems in the systems logic or architecture before they become critical failures.
24. Dependency Hell
A situation where the interdependencies of software modules make it impossible to update or modify the system without a total collapse.
25. Intent-Revealing Code
Writing code that clearly explains why it exists, not just how it works. This is the ultimate tool for reducing long-term maintenance costs.
Frequently Asked Questions
Q: Why do these definitions focus so much on logic and debt? A: Because frameworks are temporary, but bad logic is forever. Most production failures happen not because the language failed, but because the engineers mental model of the system was disconnected from reality.
Q: Is this Glossary just for Senior Architects? A: No. If youre writing code, youre building architecture. Whether youre a Junior trying to avoid Primitive Obsession or a Lead fighting Dependency Hell, these concepts are the basic tools of the trade.
Q: Can I suggest a term to be added? A: Absolutely. If youve encountered a specific code smell or architectural trap that isnt listed here, send it to us via the contact page. Were building a living library of engineering truth.
// Final Thought
Terminology is only useful if it leads to better systems. Use this glossary as a reference, but remember: the best architecture is the one that solves the problem with the least amount of code.