Nate Meyvis

Fix it how many times?

In a famous piece, Joel Spolsky advocates for "fixing it twice":

Almost every tech support problem has two solutions. The superficial and immediate solution is just to solve the customer’s problem. But when you think a little harder you can usually find a deeper solution: a way to prevent this particular problem from ever happening again.

The article changed how I think about software. But what's special about N = 2? Here are some problems, and what you might do to fix them N times:


Problem: Some title text is too bold, and it dominates the viewer's experience too much.

Possible fixes:

  1. Make that text smaller and less bold.
  2. Define a relevant CSS class and apply it to all titles.
  3. Define a relevant CSS class, apply it to all titles, and add linting rules to prevent CSS from being applied to text except by means of CSS classes.

Problem: A button hangs forever in the spinny "processing" state when a back-end call fails.

Possible fixes:

  1. Modify that button's logic to perceive and respond to a failed request.
  2. Add tests that ensure that all calls to that back-end function give good responses in all success and failure modes.
  3. Add tests that ensure that all calls to all back-end functions give good responses in all modes.

Problem: An SQL query fails and breaks part of your site silently.

Possible fixes:

  1. Fix the SQL.
  2. Fix the SQL and add a note to the README warning future developers about this failure mode.
  3. Modify the code to log the SQL query right before it's used and its first (up to) three returned rows right after the call returns.
  4. Modify all the SQL queries you make in code to behave that way.
  5. All of the above, and also add strong language to AGENTS.md and your "don't call something done before you go through this checklist" document telling your AI tools to do (4).

These decisions would all depend on context, and there's lots of room for reasonable disagreement. But I'd note that:

  1. There are plenty of cases where the "superficial" N=1 fix is the right one, and anything else adds too much complexity.
  2. In the last (SQL) case, I'm currently defaulting to N=5; this is the sort of thing that AI enables at low cost, and it's hugely valuable.1
  3. There really does seem to be something special about N=2 in a lot of cases.
  4. Most importantly, I find it valuable just to ask myself this question explicitly: "what is N here?" So much of software is figuring out what level of generality to work at. It's easy to work at too superficial a level, and it's almost as easy to over-generalize, but in my experience it's almost impossible to ask yourself "what is N here?" too often.

  1. ...but remember not to log sensitive information you shouldn't be logging.

#software