Do Frameworks Really Damage Software Maintainability?

What is a framework?

First, let’s clarify the exact meaning of a framework. A software framework is a set of specifications and components that implement industry‑standard tasks or provide basic functionality required by those specifications.

Key differences between a framework and a regular code library include:

Inversion of control: the framework, not the caller, dictates the program’s control flow, usually via templates.

Extensibility: users can extend the framework by writing custom code for specific features.

Immutable framework code: the framework itself should not be modified, only extended.

Frameworks aim to provide functionality, behavior, flow, and defaults, many of which are unchangeable. While they can bring benefits, they also introduce maintenance challenges, particularly for web services, APIs, and full‑stack applications.

What does “harm maintainability” mean?

Maintenance is divided into corrective, preventive, perfective, and adaptive categories, but for this article all post‑deployment changes are considered maintenance. Any factor that hinders ongoing maintenance—such as slower feature rollout due to framework constraints—is deemed harmful.

Three specific harms are identified:

Frameworks may speed up early development but later slow down new feature delivery.

Framework‑related tasks (upgrades, deprecations, learning new features) consume resources without delivering customer value.

Future framework evolution may diverge from project needs, breaking compatibility.

Frameworks and personal or team goals differ

Ruby on Rails founder DHH noted that while frameworks promise great things, they make no guarantees and evolve according to the creator’s preferences, leaving users to follow like loyal dogs.

Many web frameworks (Django, Rails, Spring, Gatsby, Symfony) market maintainability, yet reports show that using such frameworks does not guarantee project success and can even worsen outcomes.

Trade‑offs in framework design can jeopardize maintainability

Framework creators prioritize development speed and scalability, often at the expense of maintainability. Generated boilerplate code and extensive inheritance inflate the codebase, creating “code rot.”

class Post < ActiveRecord::Base
end

This single model can expose hundreds of public methods that developers must maintain, binding the project tightly to the framework.

Frameworks may deprecate or modify methods arbitrarily, forcing users to adapt or rewrite large portions of code.

def create
  if User.exists?(email: params[:email])
    render :new, status: :already_exists
  elsif user.save
    flash[:success] = flash_message_for(@user, :successfully_created)
    redirect_to edit_admin_user_path(@user)
  else
    render :new, status: :unprocessable_entity
  end
end

def user_params
  params.require(:user).permit(:use_billing, role_ids: [], ship_address_attributes: permitted_address_attributes, bill_address_attributes: permitted_address_attributes)
end

This intermixing of HTTP handling, business logic, and security concerns makes the code hard to read and maintain.

Frameworks are built to control your project

Using a framework tightly couples your code to its abstractions (e.g., ORM, HTTP layer). Even if you swap databases, you remain bound to the framework’s ORM and conventions, limiting flexibility.

Adopt frameworks in a decoupled way to enjoy benefits without harming maintainability

Separate concerns: place HTTP routing, authentication, and messaging in dedicated layers, exposing simple domain‑oriented interfaces (e.g., messenger.deliver(recipient, body), expenses_repository.add(expense)). This isolates framework impact and keeps core business logic clean.

Why don’t we have such a framework?

Because building a framework without relying on another defeats its purpose, and many projects evolve beyond the original framework’s scope (e.g., moving from HTTP to event‑bus or from relational DBs to other storage). Simple patterns like CQRS can replace heavyweight frameworks, and best practices emphasize not letting frameworks dictate project architecture.