[BoorishBears]

Chasing code quality and code-quality-adjacent metrics often results in buggy apps.

Copying and pasting a line of code can become a future bug when someone doesn't refactor a line of code. But building some overwrought framework to avoid ever repeating anything can introduce classes of bugs that are much much harder to solve because of the layers of indirection.

And depending on what vertical you're in, sometimes releasing something is the best path to a more reliable app. If you're writing crud apps where 99% of the complexity is defined by business rules, getting a V1 out so you can learn all the places where the business rules were improperly captured gets you a better result than bikeshedding endlessly about having the most polished version of those broken assumptions.

tl;dr: sometimes "worse code" leads to a legitimately better end product for your users.

[WalterBright]

> building some overwrought framework to avoid ever repeating anything can introduce classes of bugs that are much much harder to solve because of the layers of indirection

The development of an engineer:

1. newbie - follow the rules because you're told to

2. master - follow the rules because you understand them

3. guru - break the rules because your knowledge transcends them

I often see code that follows the rules right into a swamp. Your example is a fine illustration of this.