I have recently been going back and adding nice little notices to the tops of the previous versions of my website,¹ which read something like:

This version of the site is now archived. See the next version at v5.chriskrycho.com.

I had the idea to add this affordance a few years ago, and a former colleague² noted that it had tripped up him and several other folks recently, so I decided to go ahead and fix it once and for all. When I first had this idea, I thought I would tackle it by writing a script that could actually go find all the relevant places to insert comments using an actual HTML parser, and thereby do it “right”. After all, you cannot parse HTML with regex, right?

Well. No. You cannot. But that is not what I needed to do here. All I needed to do here was something incredibly simple and dumb, and the right way to do it was a dumb way: with a regular expression. You see, I am not dealing with arbitrary content, or documents which may be ill-formed, or any of the other many good reasons why you actually should not use a regular expression for general-purpose XML or HTML document handling. Instead, I was dealing with a very simple find-and-replace operation on HTML documents who structure I knew to be identical, because I was the sole author of those documents, and created them with well-structured templates.³

So I opened BBEdit, my tool of choice these days for this kind of text transformation or editing, wrote a little not-even-a-regex search query for the tag I wanted to insert the new element in front of, and a replacement text consisting of the new HTML element and its contents and associated styles. Then I ran Replace All, checked that things had worked the way I wanted, and repeated the process in conjunction with some judicious deployment of jj restore --from main.⁴ The details varied a little bit depending on the site in question, but those were the broad strokes. The whole thing took me maybe 20 minutes per site.

The lesson here is not “you should always do the dumb thing with a regex”. It is, rather, “sometimes you should do the dumb thing with a regex”, because that is all it takes to get the job done, and you won’t be revisiting it in the future. If either of those things is not true — if there is a more general problem to be solved, or if you expect to revisit it in the future — then build something more capable, more amenable to future revision. Otherwise… don’t.

This is what YAGNI is really about, in the end. Build what you need to do the job in front of you, aware of the future but not for the future.