3 ms·

Quick and dirty is rarely quick and always dirty. (Don't know if it has a name)

• sagartewari01 8y ago
  Especially in the java world. It can no longer be considered quick by the time IDE boots up.
• yoz-y 8y ago
  First time hearing this one. I really like it.
• tabtab 8y ago
  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.