title: are projects with high developer turn over rate really a bad thing?
body: <p>I've inherited a lot of web projects that experienced high developer turn over rates.   Sometimes these web projects are a horrible patchwork of band aid solutions.  Other times they can be somewhat maintainable mosaics of half-done features each built with a different architectural style.  Everytime I inherit these projects, I wish the previous developers could explain to me why things got so bad.</p>
  
  <p>What puzzles me is the reaction of the owners (either a manager, a middle man company, or a client).  They seem to think, "Well, if you leave, I'll find another developer, because you're expendable."   Or they think, "Oh, it costs that much money to refactor the system?   I know another developer who can do it at half the price.  I'll hire him if I can't afford you."   I'm guessing that the high developer turn over rate is related to the owner's mentality of "My ideas are always great ideas, and if you don't agree, I'll find another (possibly cheaper) developer who agrees with me and does what I want".  For the owners, the approach seems to work because their business is thriving.  Unfortunately, it's no fun for developers because they go AWOL after 3-4 months of working with poor code, strict timelines, and insufficient client feedback.</p>
  
  <p>So my question is the following:</p>
  
  <p>Are the following symptoms of a project really such a bad thing for business?</p>
  
  <ul>
  <li><p>high developer turn over rate</p></li>
  <li><p>poorly built technology - often a patchwork of different and inappropriately used architectural styles</p></li>
  <li><p>owners without a clear roadmap for their web project, and they request features on a whim</p></li>
  </ul>
  
  <p>I've seen numerous businesses prosper with the symptoms above.  <strong>So as a programmer, even though my instincts tell me the above points are terrible, I need to take a step back and ask, "are things really that bad in the grand scheme of things?"</strong>  If not, I will re-evaluate my approach to these projects..ie. Do I build long term solutions or band-aid solutions?</p>
  
  <p>** At the risk of this post being closed as non-programming related, I'd like to argue that I think it is programming related because answers to this question will influence the way a developer approaches a project.  He will have a better feel for how far in advance he should plan his development (ie. build short term or long term solution) knowing he may quit at any moment.</p>