You can have quick-and-dirty for initial release, but it's rarely practical from a maintenance perspective.

A related rule: Design software for maintenance, not initial roll-out, because maintenance is where most of the cost will likely be.

An exception may be a start-up where being first to market is of utmost importance.

Other rules:

Don't repeat yourself: factor out redundancy. However, redundancy is usually better than the wrong abstraction, which often happens because the future is harder to predict than most realize.

And Yagni: You Ain't Gonna Need It: Don't add features you don't yet need. However, make the design with an eye on likely needs. For example, if there's an 80% probability of a need for Feature X, make your code "friendly" to X if it's not much change versus no preparation. Maybe there's a more succinct way to say this.

First time hearing this one. I really like it.

Especially in the java world. It can no longer be considered quick by the time IDE boots up.