title: SOLID vs. YAGNI
body: <p>One of the most frequent arguments I hear for not adhering to the <a href="http://en.wikipedia.org/wiki/SOLID" rel="noreferrer">SOLID</a> principles in object-oriented design is <a href="http://en.wikipedia.org/wiki/YAGNI" rel="noreferrer">YAGNI</a> (although the arguer often doesn't call it that): </p>
  
  <p><em>"It is OK that I put both feature X and feature Y into the same class. It is so simple why bother adding a new class (i.e. complexity)."</em> </p>
  
  <p><em>"Yes, I can put all my business logic directly into the GUI code it is much easier and quicker. This will always be the only GUI and it is highly unlikely that significant new requirements will ever come in."</em></p>
  
  <p><em>"If in the unlikely case of new requirements my code gets too cluttered I still can refactor for the new requirement. So your 'What if you later need to…' argument doesn't count."</em></p>
  
  <p>What would be your most convincing arguments against such practice? How can I really <em>show</em> that this is an expensive practice, especially to somebody that doesn't have too much experience in software development.</p>