YAGNI — You Aren't Gonna Need It principle
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
YAGNI means not implementing a capability only because it may be needed in the future. Every extra option becomes code that must be understood, tested, secured, documented, and maintained, even if no user receives value from it.
For example, an order service may currently use one database. Creating file, cloud-object, and in-memory production storage implementations 'just in case' adds work based on guessed requirements. A clean boundary around persistence can keep the service changeable; a second adapter should be built when the real use case defines consistency, query, and failure requirements.
The principle does not ban planning. Known regulatory rules, public API compatibility, data migrations, security controls, or costly infrastructure choices may need early attention. YAGNI separates evidence-backed constraints from speculative features: design for what is known, avoid unused machinery, and extend when a real need appears.
YAGNI — You Aren't Gonna Need It principle
Direct Answer
YAGNI means not implementing a feature or flexibility only because it might be useful someday. Build for the requirements and evidence you have now, while leaving room to change. It does not mean ignoring known roadmap work, security, compliance, migrations, or decisions that are expensive to reverse.
Code Example
// Violates YAGNI: building for imagined future requirements
public class UserService {
// No one asked for multiple storage backends yet
private final StorageStrategy storageStrategy;
public UserService(StorageStrategy storageStrategy) {
this.storageStrategy = storageStrategy;
}
public void saveUser(User user) {
storageStrategy.save(user);
}
}
interface StorageStrategy {
void save(User user);
}
class DatabaseStorage implements StorageStrategy { /* ... */ }
class FileStorage implements StorageStrategy { /* ... */ }
class CloudStorage implements StorageStrategy { /* ... */ }
// YAGNI fix: implement what's needed today
@Service
public class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public void saveUser(User user) {
userRepository.save(user);
}
}
// When you actually need multiple backends later, refactor then
// For now, the simple version does the job
Common Mistakes & Pitfalls
- Confusing YAGNI with no planning: keep known security, compatibility, migration, and capacity constraints visible.
- Calling an accepted requirement hypothetical: committed near-term work may need a design decision today.
- Building complete speculative implementations: a clean boundary is often enough until the real variation is understood.
- Postponing irreversible decisions blindly: investigate choices whose later change cost is high.
Check your understanding
Answer these without looking back at the article.
- How does YAGNI relate to technical debt?
- Is there ever a good reason to build something you do not need yet?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.