Oh I've seen this many times in different forms. Especially with regexes. You know what this is a great example of? A case where hacking makes a mess, and thin

Oh I've seen this many times in different forms. Especially with regexes. You know what this is a great example of? A case where hacking makes a mess, and thinking before coding solves the problem. The madness comes from using the wrong tool for the problem. Yes, you can hack a regex to parse XHTML this might be "good enough", but it is more robust, cleaner and easier to explain if you use a lexical tokenizer and a grammar. The lure is an illusion that comes from an initial effort assessment. Where the effort to hack a quick-and-dirty regex (call this Ehack) vs a "oh, man, you mean I gotta think about the problem" (call this Ethink) appears as "Equick <<< Ethink." However, it soon evolves to the scenario where "Equick >>> Ethink," driven by the thought process, "I'm almost there, this regex just needs one more tweak." Aka, the gambler's fallacy: it comes into play and the sunk costs are ignored. TL;DR - Use the right tool for the problem, even if it means a slightly larger up-front effort investment.