At Least Twice

The opposite of OnceAndOnlyOnce.

This is a lot of work to write and a lot of work to read. There are too many inconsistencies and they are too hard to find.

See also TwiceAndOnlyTwice.

This can also be a strategy employed in which one retains copies for Backup or Historical purposes. In the second case eventually the copy will differ from the current and if not also backed up, will exist OnceAndOnlyOnce.

Additionally, it can be a strategy to approach solid design without risking AnalysisParalysis. Rather than trying to code OnceAndOnlyOnce and hoping to get it right the first time, you don't fear coding things twice. This helps meditating over the approach taken first and trying to fix some details you didn't like there. As the code evolves, one of the two approaches will probably fade out. In some cases, it is even valuable to have the "worse" code still handy if it turns out that the "better" code has some flaws that did not pop up earlier. This could be seen as some kind of semantic redundancy.