title: Concrete symptoms of over-engineering
body: <p>I have recently found myself in the position of explaining an (In-House) application I have written to two candidates my company likes to hire in order to assist in maintenance and adding minor features.</p>
  
  <p>It is the first "production" application I have written, it has 45k LOCs and I spent almost two years of "solo" development on it. I am fairly young (18) and wrote the application from scratch while being contracted as stand-in for a former developer who left the company. Unexperienced in designing applications of this size, I tried to use common architecture- and design-patterns. </p>
  
  <p>Today I know I have done some serious over-engineering, e.g. using a disconnected change tracking architecture instead of the Unit Of Work pattern, which the chosen ORM has  already implemented. I will probably never have to go "real" three tiers.</p>
  
  <p>Both candidates have 10 years+ background in In-House Application Development with the relevant platform. Being half their age and having little experience I do respect their opinion. When I was explaining the application architecture to them, comments were along the lines of:</p>
  
  <ul>
  <li>Jeez, no one would pay me to do stuff like that, I have to get things done</li>
  <li>Stick with what the framework does, don't use fancy libraries/technologies</li>
  <li>Don't wrap framework code. On a team, everyone will write his own wrapper code anyway.</li>
  <li>You're using .NET 3.5? Well, we are using 2.0.</li>
  <li>What does that LINQ stuff buy me? All this query composition and projection seems too complicated.</li>
  </ul>
  
  <p>Now I am asking myself:<br>
  Am I an <a href="http://www.joelonsoftware.com/articles/fog0000000018.html" rel="noreferrer">architecture astronaut</a>? How do I know I am going too far with architecture? What are common symptoms of over-engineering?</p>