Remove Parameter: Delete the 'Telegram Address' Field from the School Form

📮 The Telegram Address on the School Form

Admission season at Saraswati Public School. The corridor outside the office is full of parents standing in a slow queue, each holding the four-page admission form on a clipboard. Mr. Farooq, here to admit his daughter, works through it line by line. Name — fine. Date of birth — fine. Address — fine. Then comes field number 14: "Telegram Address."

Telegram? He looks up, confused. The telegram service in India closed in 2013 — his daughter was not even born then. No family in the queue has a telegram address. He leans over to the aunty next to him: "Telegram address kya likhna hai?" She shrugs and shows him her form — she has written her phone number in that box. The man behind them has written "N/A". One uncle, playing it safe, has written his email.

At the counter sits Mrs. Iyer, the office clerk of twenty-two years. Mr. Farooq asks her directly. She laughs: "Oh, that field? We never look at it, beta. Just put a dash. The form was designed in 1998 and nobody ever reprinted it properly."

But watch what this dead field costs, every single admission season:

• Every parent stops, frowns, and loses a minute — four hundred parents, four hundred minutes.
• Mrs. Iyer answers the same question dozens of times a day, instead of doing real work.
• The answers that do get written are garbage — phone numbers, emails, dashes — noise stored forever in the school's files.
• Worst of all: this year the school hired a new office assistant, Sunil. Seeing the field on an official form, he reasonably assumed it must matter — and rejected three forms for leaving field 14 blank. Real families, real delays, caused by a field that has been meaningless for over a decade.

A dead field on a form does not sit quietly. It misleads everyone who touches the form, wastes a little of everyone's time, and occasionally — through an honest newcomer like Sunil — causes real mistakes. The fix costs five minutes at the printer: reprint the form without field 14.

Methods have forms too — their parameter lists. A parameter the method no longer reads is a telegram-address field: every caller dutifully computes and passes a value that vanishes into nothing, and every reader assumes it matters. Remove Parameter is the reprinting of the form: delete the dead field, fix the callers, and let the signature tell the truth again.

What is Remove Parameter? 🧐

Remove Parameter is a refactoring from Martin Fowler's Refactoring book:

Delete a parameter that the method body no longer uses.

The reasoning is beautifully simple. Every parameter is two things at once:

1. A question the caller must answer. "What region? What currency? What date?" Callers must find or compute a value for every parameter, every time.
2. A promise to the reader. A parameter in the signature says: this value influences what I do. Readers plan around that promise.

An unused parameter breaks both. Callers answer a question nobody asked. Readers trust a promise that is a lie. The cost is small per occurrence but it never stops accruing — like the telegram field, it taxes every form-filler forever. And once in a while it produces a Sunil: a conscientious newcomer who takes the dead field seriously and breaks something real because of it.

How do these zombies appear? Almost never on purpose:

• Refactoring leftovers. The body once read region to pick a tax rate; then tax became a flat rate, the region logic was deleted — but the parameter stayed, because deleting it meant touching all the callers and someone was in a hurry.
• Speculative generality. "Let's accept a currency parameter — we might go international someday." Five years later: still only rupees, and the parameter never consulted. This is the Speculative Generality smell wearing a parameter costume.
• Copy-paste inheritance. A method copied from a sibling kept the sibling's full signature, though this version needs less.

One mindset shift makes this refactoring click: deleting code is progress. Beginners feel that removing things is "negative work". Professionals know that every line, every field, every parameter that exists must be read, understood, tested, and maintained — forever. The cheapest code to maintain is the code that is not there.

The whole topic, on one page:

College corner: removing a parameter from a published API is a textbook breaking change — stricter than adding one. Adding can be backward compatible (old callers ignore the new optional field); removing never is, because existing call sites are now passing an argument the function no longer accepts. This is why public APIs run removals through a deprecation pipeline: announce, mark deprecated, keep a compatibility shim that accepts-and-ignores the old argument, and drop it only at the next major version. REST APIs do the same with request fields — servers commonly accept and ignore unknown or retired fields for years (a policy sometimes summarised as "be liberal in what you accept"), precisely so old clients do not break the day a field dies.

When Do We Need It? 🚨

Look for these triggers:

1. The body never reads the parameter. The simplest case. Your linter probably already underlines it — TypeScript's noUnusedParameters, ESLint's no-unused-vars, and .NET analyzers all flag this.
2. The parameter is read but changes nothing. Sneakier: the value is logged and forgotten, or assigned to a variable nobody uses. Functionally dead, just better camouflaged.
3. Callers visibly struggle to supply it. When call sites pass null, undefined, "", or a comment like /* not used? */, the callers have already discovered the field is dead — the signature just has not admitted it yet. This is the queue inventing answers for field 14.
4. A refactoring just removed the using code. Best moment of all: you simplified the body two minutes ago. Clean the signature now, while you remember why, instead of leaving a mystery for next year's reader.
5. The method can compute the value itself. Special case with its own name: if the method can derive the value from its other arguments or its own state, do not make the caller pass it — that is Replace Parameter with Method Call, a close cousin.

And the stop signs — situations where an "unused" parameter must stay:

• An interface or base class demands it. If process(order, context) implements an interface, this implementation may ignore context, but the signature belongs to the contract. Remove it from the contract (and the whole family) or not at all.
• Sibling overrides use it. In a template-method design, the base passes data that only some subclasses consume. Your subclass ignoring it does not make it dead — check the family.
• A framework binds it by name or position. Route handlers, event callbacks, DI-injected factory methods — frameworks often call you with a fixed argument shape. Removing a parameter shifts the positions and breaks the binding.
• Delegates and callbacks. If the method is assigned where a specific function type is expected — (event, index) => void — the shape is fixed from outside.

Want proof that a dead field produces only garbage? Mrs. Iyer once tallied what four hundred parents actually wrote in the telegram box:

In code, this chart is the nulls, empty strings, and /* whatever */ comments that pile up at call sites of a method with a zombie parameter. The callers have already voted: the field is dead.

Once you are sure it is dead, how aggressively can you delete? Two questions decide: how many callers, and is the signature part of a contract?

Before and After at a Glance 📋

Here is the telegram field in TypeScript:

// BEFORE — "region" is the telegram address
function priceWithTax(amount: number, currency: string, region: string): number {
  // Once upon a time, region picked a tax rate.
  // Since the 2024 flat-tax change, it is never consulted.
  return amount * 1.18;
}
 
// Every caller still pays the tax of computing region:
const region = lookupRegionFromPincode(customer.pincode); // wasted work!
const total = priceWithTax(amount, "INR", region);

Notice the double damage: the caller performs a real lookup (lookupRegionFromPincode) purely to feed a dead field, and the reader of priceWithTax naturally assumes regional tax logic exists somewhere.

// AFTER — the form reprinted without the dead field
function priceWithTax(amount: number): number {
  return amount * 1.18;
}
 
// The caller sheds the wasted lookup too:
const total = priceWithTax(amount);

Two parameters gone (currency was also unused — did you spot it?), one wasteful lookup deleted at the call site, and the signature finally tells the truth: this price depends on the amount, nothing else.

Step-by-Step, the Safe Way 🪜

Deleting looks easy — that is exactly why people skip the checks and get burned. The full pipeline:

Step 1 — Prove the parameter is dead, four ways.

1. Body: no read of the parameter (your IDE greys it out or the linter flags it).
2. Family: no override, no sibling implementation, no interface/base declaration uses it.
3. Frameworks: no DI, serializer, router, or test harness binds arguments by name/position to this method.
4. Dynamic calls: search for the method name as text — reflection or dynamic dispatch may pass arguments positionally.

Step 2 — If the method is polymorphic, plan the family change. The parameter must be removed from the interface/base and every implementation in one coordinated move, or from none. Signatures in a family must stay compatible.

Step 3 — For public APIs, stage it with a delegating overload. Do not yank the field off a form other departments still print. Add the clean signature, keep the old one forwarding, and deprecate:

// INTERMEDIATE — both shapes work; old one warns
function priceWithTax(amount: number): number {
  return amount * 1.18;
}
 
/** @deprecated currency and region are ignored; call priceWithTax(amount). */
function priceWithTaxLegacy(amount: number, currency: string, region: string): number {
  return priceWithTax(amount);
}

(In C# or Java this is a true overload of the same name plus [Obsolete]/@Deprecated; we will see it below.)

Step 4 — Remove the parameter from the declaration (internal callers). In a typed language, now comes the magic: compile, and the compiler hands you a complete to-do list. Every red error is a caller passing an argument that must be deleted.

Step 5 — Fix each caller, and clean upstream waste. At each call site, delete the dead argument — and look one line up. Very often the caller computed that value just to pass it. Delete the computation too. Sometimes the cleanup cascades beautifully: the lookup function loses its last caller and can itself be deleted.

// caller, before:
const region = lookupRegionFromPincode(customer.pincode);
const total = priceWithTax(amount, "INR", region);
 
// caller, after — the lookup goes too:
const total = priceWithTax(amount);

Step 6 — Run the full test suite. Behaviour must be byte-for-byte identical. The only thing that changed is honesty.

During the staged period, a legacy caller's arguments flow through the shim and simply fall away:

And the codebase's overall journey has the same safe middle state as every Change Function Declaration move:

College corner: that position-shifting bug deserves a name you will meet again: positional coupling. Any caller that passes arguments by position — reflection invocations, JavaScript callbacks, Python *args forwarding, serialized RPC frames — depends on the order and count of parameters, not their names. Removing parameter two silently turns the old argument three into the new argument two. Typed languages catch the count mismatch; dynamic languages and binary protocols often do not. This is one reason modern API styles favour named fields over positional ones (keyword arguments, JSON bodies, protobuf field numbers): they make signature evolution — in both the add and remove directions — dramatically safer.

A Bigger Real-Life Example 🏥

A hospital appointment system, four years old. The booking method has collected zombie parameters the way an old drawer collects dead pens:

// BEFORE — count the telegram addresses
class AppointmentService {
  bookAppointment(
    patientId: string,
    doctorId: string,
    slot: TimeSlot,
    faxNumber: string,        // fax confirmations stopped in 2022
    insuranceCode: string,    // insurance module was split into its own service
    isLegacyPatient: boolean, // migration finished; everyone is "new system" now
  ): Appointment {
    const appointment = new Appointment(patientId, doctorId, slot);
    this.repo.save(appointment);
    this.sms.sendConfirmation(patientId, slot);
    return appointment;
  }
}

Three of six parameters are dead. Now look at what a caller must do today:

// A caller, suffering in silence:
const fax = patient.faxNumber ?? "";                    // wasted lookup
const insurance = await insuranceApi.getCode(patient);  // wasted NETWORK CALL!
const appointment = service.bookAppointment(
  patient.id,
  doctor.id,
  chosenSlot,
  fax,
  insurance,
  false, // what does false mean here? new reader has no idea
);

A network call is being made on every booking to fetch an insurance code that is thrown away. That is the telegram field at its worst: not just confusing, but actively wasting time and money.

Run the four checks: body — no reads (confirmed by the linter); family — AppointmentService is a concrete class, no interface declares this method; frameworks — called directly from controllers, not bound by shape; dynamic — text search finds no reflection. All clear. Reprint the form:

// AFTER — the honest signature
class AppointmentService {
  bookAppointment(patientId: string, doctorId: string, slot: TimeSlot): Appointment {
    const appointment = new Appointment(patientId, doctorId, slot);
    this.repo.save(appointment);
    this.sms.sendConfirmation(patientId, slot);
    return appointment;
  }
}
 
// The caller becomes shorter, faster, and clearer:
const appointment = service.bookAppointment(patient.id, doctor.id, chosenSlot);

The two class shapes, side by side:

The wins, counted:

1. One network call per booking — gone. Real performance, gained by deleting code.
2. The mysterious false — gone. No reader will ever again wonder what it meant.
3. Tests shrank. Old tests fabricated fax numbers and insurance codes just to satisfy the signature. New tests state only what matters.
4. The signature is a true document. Booking depends on patient, doctor, slot. Exactly what a newcomer would guess, and now exactly what the code says.

And because callers shed real upstream work (that insurance lookup!), the payoff is measurable, not just aesthetic:

The Same Refactoring in C# 🎯

C# shows the staged, public-API-safe version best. Here is a report generator whose format parameter died when PDF became the only supported output:

// BEFORE — "format" is dead; PDF won the war in 2024
public class ReportGenerator
{
    public byte[] Generate(int reportId, string format, bool useLegacyEngine)
    {
        // format ignored — PDF always; legacy engine deleted long ago
        var data = _repo.LoadReport(reportId);
        return _pdfEngine.Render(data);
    }
}

Step 1 — introduce the clean overload; make the old one delegate and warn:

public class ReportGenerator
{
    // NEW — the honest signature
    public byte[] Generate(int reportId)
    {
        var data = _repo.LoadReport(reportId);
        return _pdfEngine.Render(data);
    }
 
    // OLD — kept temporarily for external callers
    [Obsolete("format and useLegacyEngine are ignored. Call Generate(reportId).")]
    public byte[] Generate(int reportId, string format, bool useLegacyEngine)
        => Generate(reportId);
}

Every existing caller compiles, behaves identically, and sees a warning pointing at the clean method. Internal callers migrate immediately (the compiler-warning list is the to-do list). External teams migrate over a release cycle. Then:

// AFTER — final state
public class ReportGenerator
{
    public byte[] Generate(int reportId)
    {
        var data = _repo.LoadReport(reportId);
        return _pdfEngine.Render(data);
    }
}

C#-specific care points:

• Interface members: if Generate lives on IReportGenerator, change the interface and all implementations together — an implementation cannot drop a parameter on its own.
• Intentionally unused parameters that must stay (contract-bound) can be named _ in C# (discard naming convention), telling readers "ignored on purpose, not by accident."
• Analyzers help: .NET code-quality rule CA1801 / IDE0060 ("Review unused parameters") flags these zombies automatically in the build. Turn it on and the telegram fields reveal themselves.

A Quick Python Taste 🐍

Python has no compiler to list broken callers, so the staged shim plus a runtime warning is the standard play:

import warnings
 
def price_with_tax(amount: float) -> float:
    """The clean, honest signature."""
    return amount * 1.18
 
def price_with_tax_legacy(amount: float, currency: str, region: str) -> float:
    """Deprecated: currency and region are ignored."""
    warnings.warn(
        "currency and region are ignored; call price_with_tax(amount)",
        DeprecationWarning,
        stacklevel=2,
    )
    return price_with_tax(amount)

One Python-specific trap: a caller using keyword arguments — price_with_tax(amount=100, region="south") — raises TypeError the moment region disappears, but a caller forwarding positionally through *args may silently mis-bind. Search for both the function name and the parameter names as text before declaring victory.

IDE Support 🛠️

Signature surgery is automated in every major IDE — the same "Change Signature" tooling that adds parameters also removes them:

One honest warning about automation: the IDE removes the argument expression at each call site, but it will not notice that the caller computed that value two lines earlier for no other purpose. The wasted lookupRegionFromPincode() line stays unless you look for it. After an automated removal, visit each changed call site once with human eyes.

Benefits and Risks ⚖️

Which Smells Does It Cure? 🧹

Quick Revision Box 📦

+----------------------------------------------------------------+
|                REMOVE PARAMETER — CHEAT SHEET                   |
+----------------------------------------------------------------+
| Story    : Delete "Telegram Address" from the school form      |
| Goal     : Signature lists ONLY values the method really uses  |
| 2nd ed.  : Part of "Change Function Declaration" (Fowler)      |
| Inverse  : Add Parameter (same seesaw, other direction)        |
|                                                                |
| PROVE IT IS DEAD (all four):                                   |
|   1. Body never reads it                                       |
|   2. No override / interface / sibling needs it                |
|   3. No framework binds by name or position                    |
|   4. No reflection / dynamic call passes it                    |
|                                                                |
| SAFE STEPS: stage with delegating overload if public ->        |
|   delete from declaration -> compiler lists callers ->         |
|   fix each caller AND delete upstream wasted work -> ALL tests |
|                                                                |
| IDE      : JetBrains Ctrl+F6 | VS Ctrl+R,Ctrl+V                |
| Radar    : noUnusedParameters / IDE0060 / CA1801               |
+----------------------------------------------------------------+

Practice Exercise ✍️

A food-delivery app has this restaurant-rating function. The team suspects zombie parameters:

class RatingService {
  submitRating(
    orderId: string,
    stars: number,
    comment: string,
    deviceImei: string,      // collected "for fraud checks" planned in 2023, never built
    appVersion: string,      // logged once upon a time; the log line was deleted
    restaurantTier: string,  // hmm... check carefully!
  ): Rating {
    const rating = new Rating(orderId, stars, comment);
    this.repo.save(rating);
    this.notifier.informRestaurant(orderId, stars);
    return rating;
  }
}
 
// Elsewhere in the codebase:
class PremiumRatingService extends RatingService {
  override submitRating(
    orderId: string, stars: number, comment: string,
    deviceImei: string, appVersion: string, restaurantTier: string,
  ): Rating {
    if (restaurantTier === "premium" && stars <= 2) {
      this.escalation.alertAccountManager(orderId);  // uses restaurantTier!
    }
    return super.submitRating(orderId, stars, comment, deviceImei, appVersion, restaurantTier);
  }
}

Tasks:

1. Run the four-check test on each suspect parameter. Which of deviceImei, appVersion, restaurantTier are truly dead, and which one is a trap? (Hint: read the subclass with full attention.)
2. Remove the genuinely dead parameters in stages: show the intermediate state (clean signature + deprecated delegating method) and the final state of both classes. Mark which state of Figure 7 each snapshot represents.
3. One caller currently does const imei = await device.readImei(); before calling submitRating. What should happen to that line, and why is this kind of cleanup the hidden bonus of Remove Parameter?
4. The team lead says: "Keep deviceImei — we might build the fraud system next year." Write two sentences responding, using the term speculative generality, and state what it would cost to re-add the parameter later if the system really gets built. (Remember: Add Parameter exists precisely for that day, with its own safe staging.)
5. Bonus: restaurantTier survives the deletion — but could the design improve so the base class signature does not carry premium-only data? Sketch one alternative (hint: could PremiumRatingService fetch the tier itself from orderId? That is Replace Parameter with Method Call.)

If you correctly spared restaurantTier from deletion, congratulations — you have learned the deepest lesson of this refactoring: unused in one body does not mean unused in the family. Reprint the form, but read every copy of it first. Mrs. Iyer checked with the records room before scrapping field 14; so should you.