The Title Did Not Need a Second Set of Rules

The request was only for a more distinctive title, but the first answer would have given that title a second set of rules to carry around. That kind of small decision can cost time for years, because every new rule needs someone to remember it, explain it, fix it, and make sure it still works.

I started with the request itself: make a title feel more distinctive. It sounded like a request for a brand-new choice. When the assistant proposed a separate title style, another option beside the ones already there, I went with it. I asked for a prototype on a local copy of the site so I could see it. The picker gained a fourth choice next to the three that were already in it, and it looked like the job was done.

It did not hold up for long. Looking at that fourth choice, I told the assistant it seemed wrong. The standard title was the whole point of the existing style, and the back end should already have controls for this. It would have made the title look different, but it would also have started a second little system inside the product. The new choice would need its own rules about where it appears, how it is saved, what happens when someone changes their mind, and how it should behave when it does not belong on a particular screen. It would need explaining. It would need checking whenever related parts of the product changed. It would give people one more way to reach almost the same result.

The cost would not have arrived as one dramatic bill. It would have shown up in small pieces. A few extra minutes when someone changes a setting. A confused question about why one title choice appears here but not there. A future update that has to touch two places instead of one. Those are the chores that wear out attention. Nobody enjoys spending an afternoon tracking down why two nearly identical choices behave differently.

So I went back to the nearby controls instead of drawing a new box on the page. There was already a title style that could do the job. What was missing was not the style itself. What was missing was a clear way for someone to use it.

That changed the question. Instead of asking, “What new title option should we build?” I asked, “What does the title option already do, and what is keeping the right person from reaching it?” The answer was a smaller change with a better shape. Expose the existing controls that make the current style useful.

This was not just a matter of making a familiar button visible. The existing pattern already had a way to save changes and a rule for when the control belongs on the screen. It also had behavior people would recognize from nearby settings. That is valuable because a product is not only the parts people can see. It is also the quiet decisions underneath them.

One technical word matters here: persistence. It simply means that when someone saves a choice, the choice is still there later. A new title style would have needed its own route for remembering what was picked. Using the established style meant using the route that already handled similar settings. That did not remove the need to check the work, but it meant we were not rebuilding a lock just to put it on a door that already had one.

The most useful part of the old pattern was not its appearance. It was its gate. The control showed up when it applied and stayed out of the way when it did not. A separate option would have needed to recreate that judgment from scratch. Reusing the existing gate made sense only because the new control followed the same product rule. If the situations had been meaningfully different, sharing the gate would have been a mistake dressed up as efficiency.

That is an important pause point. Familiarity can make a change feel safer than it is. A control that looks right can still show up in the wrong place, save the wrong thing, or confuse someone who should never have seen it. Before showing a change to anyone or releasing it, the sensible place to test is away from live customer work, using authorized test space or representative practice data. The questions are plain: Does it save correctly? Does it appear only where it should? Does it leave existing content alone? Can it be undone?

I also would not treat the smaller change as a reason to skip the paper trail. Someone should be able to tell what changed, who approved it, what was checked, and how to recover if the result is not right. That is not bureaucracy for its own sake. It is how a small adjustment stays small when something unexpected happens.

The good result here was not a flashy new title system. It was a title that could be made more distinctive without teaching people a second way to do the same job. The product stayed more coherent because its visible choices matched the rules already underneath them. People could find the option where they expected it, and the people maintaining it could understand it through a pattern they already knew.

The fourth title choice would have been a second copy of a decision the product had already made, with its own gate, its own saved value, and its own way of going wrong on a screen where it did not belong. The existing style needed none of that. It needed its controls exposed, so one saved setting and one rule for where the control appears could keep serving both the old picker and the new request. Three choices stayed three, and the distinctive title arrived without adding a fourth thing anyone would have to remember to test.

dxdev LESSON · paste into your AI coding agent
LESSON: A request for a distinctive title almost became a whole second system instead of an existing option exposed
SOURCE: dxdev.com/blog/2026-06-02_title-did-not-need-a-second-set
WHAT HAPPENED: A request to make a page title feel more distinctive was first answered by prototyping a new, fourth title style option alongside three that already existed in the picker. Reviewing the prototype, the requester pointed out that the standard title style was already meant to do this job, and the back end should already have controls for it. Building the new option instead would have created a second small system requiring its own rules for where it appears, how it saves, meaning a saved choice is still there later, what happens when someone changes their mind, and how it behaves when it doesn't belong on a screen. The actual fix was smaller: expose the existing controls for the style that already existed, reusing its established save route and its existing gate for when the control should appear, rather than rebuilding that judgment from scratch for a new option.
THE RULE: Before building a new option, list, or config path in response to a feature request, check whether an existing pattern already does the job and only needs to be exposed or made reachable. A new option that duplicates an existing one's purpose costs more in maintenance, explanation, and edge cases than it ever saves in the moment it's built.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any newly-added option, field, or config path introduced to satisfy a feature request without first checking whether an existing pattern already serves the same purpose and only needs exposing.
  2. Any new UI control built without reusing an existing save route, instead of implementing its own storage and retrieval logic for an outcome nearly identical to something that already exists.
  3. Any new control's visibility or availability rule, when it should appear, when it shouldn't, built from scratch rather than reusing an existing, already-tested gate, without confirming the two situations are actually similar enough to share that gate.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.