KISS

KISS stands for Keep It Simple, Stupid. The simplest solution is usually the best one. Avoid unnecessary complexity.

The Principle

KISS: Keep It Simple, Stupid

Most systems work best if they are kept simple rather
than made complicated.

— Kelly Johnson, Lockheed Skunk Works

Why Simplicity Matters

Simple Code:                    Complex Code:
─────────────                   ─────────────
Easy to understand              Hard to follow
Easy to modify                  Risky to change
Easy to test                    Difficult to verify
Easy to debug                   Hard to troubleshoot
Easy to onboard new devs        Steep learning curve

The Simplicity Spectrum

Too Simple ◀──────────────────▶ Just Right ◀──────────────▶ Too Complex

Missing error    Single function     Well-structured      Over-engineered
handling, no     doing everything    with clear           with unnecessary
validation       (big ball of mud)   responsibilities     abstractions

What KISS is NOT

• Not lazy: Simple ≠ incomplete
• Not skipping tests: Simple code still needs testing
• Not avoiding frameworks: Use them when they simplify
• Not dumbing down: Simple ≠ unsophisticated

Understanding what makes code complex helps you keep it simple.

Sources of Complexity

Source	Example	KISS Fix
Unnecessary abstraction	Abstract class with 1 subclass	Just use the class
Over-engineering	Plugin system for 2 options	Simple if-else
Deep nesting	5 levels of if/else	Extract methods
Tight coupling	Class depends on 10 others	Reduce dependencies
Premature optimization	Complex caching for 10 users	Simple solution first
Feature creep	Adding "just in case" features	YAGNI

Complexity Example

// BAD: Over-engineered
public class NotificationFactory {
    private static final Map<NotificationType, Supplier<Notification>> registry = 
        new ConcurrentHashMap<>();
    
    static {
        registry.put(EMAIL, EmailNotification::new);
        registry.put(SMS, SMSNotification::new);
        registry.put(PUSH, PushNotification::new);
    }
    
    public static Notification create(NotificationType type) {
        return registry.getOrDefault(type, DefaultNotification::new).get();
    }
}

// GOOD: Simple and clear
public class NotificationFactory {
    public static Notification create(NotificationType type) {
        return switch (type) {
            case EMAIL -> new EmailNotification();
            case SMS -> new SMSNotification();
            case PUSH -> new PushNotification();
        };
    }
}

Signs of Unnecessary Complexity

1. Hard to explain: If you can't explain it simply, it's too complex
2. Hard to test: Many mocks needed for simple functionality
3. Hard to change: Small changes require many modifications
4. Hard to debug: Can't trace execution easily
5. Hard to onboard: New team members take weeks to understand

Simple Design Checklist

• Can I explain this in 2 sentences?
• Does each class have one clear purpose?
• Are there fewer than 3 levels of abstraction?
• Can I test it without elaborate setup?
• Would a junior developer understand it?

Real-world examples of applying KISS in system design.

Example 1: Data Access

// BAD: Over-abstracted
public interface DataAccessStrategy<T> {
    Optional<T> retrieve(QuerySpecification<T> spec);
}

public class DataAccessStrategyFactory {
    public <T> DataAccessStrategy<T> create(DataAccessType type) { ... }
}

// GOOD: Simple and direct
public class UserRepository {
    private final Database db;
    
    public User findById(String id) {
        return db.query("SELECT * FROM users WHERE id = ?", id);
    }
    
    public void save(User user) {
        db.execute("INSERT INTO users ...", user.getArgs());
    }
}

Example 2: Validation

// BAD: Complex rule engine
public class ValidationEngine {
    private List<ValidationRule> rules;
    private ValidationPipeline pipeline;
    private RuleEvaluator evaluator;
    
    public ValidationResult validate(Object obj) {
        return pipeline.execute(rules, evaluator, obj);
    }
}

// GOOD: Simple validation
public class UserValidator {
    public void validate(User user) {
        if (user.getName() == null || user.getName().isEmpty()) {
            throw new ValidationException("Name is required");
        }
        if (!user.getEmail().contains("@")) {
            throw new ValidationException("Invalid email");
        }
        if (user.getAge() < 0 || user.getAge() > 150) {
            throw new ValidationException("Invalid age");
        }
    }
}

Example 3: Configuration

// BAD: Over-engineered config system
public class ConfigurationManager {
    private ConfigSource primarySource;
    private ConfigSource fallbackSource;
    private ConfigCache cache;
    private ConfigValidator validator;
    
    public <T> T get(String key, Class<T> type) {
        return cache.getOrCompute(key, () -> 
            validator.validate(
                primarySource.get(key, type)
            )
        );
    }
}

// GOOD: Simple config
public class Config {
    private final Properties props;
    
    public Config(String filePath) {
        this.props = new Properties();
        props.load(new FileInputStream(filePath));
    }
    
    public String get(String key) {
        return props.getProperty(key);
    }
    
    public int getInt(String key, int defaultValue) {
        String value = props.getProperty(key);
        return value != null ? Integer.parseInt(value) : defaultValue;
    }
}

KISS in System Design

Don't add:
- Caching layer if DB is fast enough
- Message queue if sync works
- Microservices if monolith is simple
- Load balancer for 100 users
- Auto-scaling for predictable load

Do add when needed:
- Caching when DB is slow
- Queue when processing is slow
- Services when teams need independence
- Load balancer when traffic grows
- Auto-scaling when load varies

The YAGNI-KISS Connection

KISS and YAGNI work together:

• YAGNI: Don't build what you don't need
• KISS: Build what you need in the simplest way

Both reduce unnecessary complexity.