Clear Code
  • Introduction
    • About This Book
    • Timeline
    • Software Killers
    • Billion Dollar Mistakes
    • Clear Code Overview
    • Clear Code Rules
  • Data Processing
    • Separate Data Collection And Processing
    • Create Data Models
    • Separate Use Cases
    • Data Should Be Immutable
  • Examples
    • Separate Use Cases With Data Model
  • Maintenance Cost
    • Consider the Maintenance Cost
    • The Software Exists In Time
    • Don't Feed the Monsters
  • OOP
    • Separate Data And Procedures
    • Do Not Use Inheritance
    • When To Avoid Inheritance?
    • What Is The Problem With Abstract Frameworks?
  • VARIOUS
    • The Real Single Responsibility Principle
    • The problem with Clean Code's name
    • How To Handle Warnings
    • Do Not Create Constant Collection Classes
  • Externals
    • Links
    • Quotes
    • Funny
  • Technology
    • Git Tutorials
  • Clean Code
    • Clean Code Introduction
      • Origin & Overview
      • Advanced
      • Typical Issues
    • Clean Code Outline
      • Why Clean Code?
      • Clean Code
      • Clean Code Approaches
      • Specification & Design
      • Duplication
      • Refinement & Refactoring
      • Conventions
      • Names
      • Types
      • Methods
      • Nulls and Validity Checks
      • Comments
      • Dead Code
      • Error Handling
      • Classes
      • Code Formatting
      • Unit Tests
      • Special Cases
      • Object Oriented Programming
      • General Code Smells
    • Clean Code Links
    • Clean Code TOC
    • Effective Java TOC
Powered by GitBook
On this page
  • The problem
  • Solution
  • Is it in the requirements?
  • Cost/benefit ratio

Was this helpful?

  1. Maintenance Cost

Don't Feed the Monsters

2023.07.14

Last updated 1 year ago

Was this helpful?

The problem

Every solution we introduce to the code comes at a price. Frameworks, layers, queues, architectural decisions, third-party tools, class hierarchies, models, techniques, and our own design ideas. This price is the .

All we should do is focus on the business logic. The user requirements. We should understand it, we should implement it, and the code should reflect it. This is called clean code.

But the technical solutions we add will distract us from the business logic. We will spend an increasing amount of time writing code that is solely required by those frameworks and solutions and which has nothing to do with the user requirements.

We must "feed" our creatures like slaves. And they are hungry!

Imagine just a simple class hierarchy. After introducing it we will have to create more and more classes and interfaces to satisfy the hierarchy and the compiler. We will have to create more and more overridden methods or split the code into more abstract methods to avoid overriding.

But remember, professional software development is not a Tamagotchi game. We don't have to do this. But how can we avoid having these hungry monsters?

Solution

Is it in the requirements?

We should investigate every solution and design decision before introducing them.

The first and most important question: Are they required by the user requirements or can they be derived from them? In other words, do they implement a requirement at all? Or are they only a possibility or a "matter of taste"?

Focus always on the business requirements and not on the solutions.

Cost/benefit ratio

The second question is: Is it worth introducing a certain solution? Do we want to pay the cost for the benefit it brings? By cost, I mean the cost of maintenance.

And this is where software development seems to fail. We have methods for everything: project management, build, delivery, code checking, etc.

Software management never estimates the maintenance cost of the design decisions.

Yes, we estimate each task we implement. But we never compare implementing a task with or without a certain technology. We have a blind spot for this. We never talk about this.

See more here: .

Consider the Maintenance Cost
maintenance cost