Glossary of Software Engineering Logic
// The Engineering Vocabulary: Beyond the Syntax
In a world obsessed with framework updates and “speed to market,” we’ve 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 isn’t a dictionary of academic definitions. It’s a curated map of the obstacles and leverage points we encounter in real-world production. We’ve 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 is the only asset that doesn’t 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 don’t just identify debt; we calculate the interest rate and prioritize refactoring based on business risk.
4. Architectural Subtraction
The engineering practice of 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 isn’t maintainable, it’s 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. It’s 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. It’s 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 don’t 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 system’s 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 engineer’s mental model of the system was disconnected from reality.
Q: Is this Glossary just for Senior Architects? A: No. If you’re writing code, you’re building architecture. Whether you’re 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 you’ve encountered a specific “code smell” or architectural trap that isn’t listed here, send it to us via the contact page. We’re 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.