are projects with high developer turn over rate really a bad thing? [closed]

Question

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.

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.

So my question is the following:

Are the following symptoms of a project really such a bad thing for business?

• high developer turn over rate

• poorly built technology - often a patchwork of different and inappropriately used architectural styles

• owners without a clear roadmap for their web project, and they request features on a whim

I've seen numerous businesses prosper with the symptoms above. 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?" If not, I will re-evaluate my approach to these projects..ie. Do I build long term solutions or band-aid solutions?

** 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.

Answer 1

All three symptoms are bad. They really are a bad thing for business. That being said:

Software development exists to make tools. That's it. It's not an end, in and of itself - you're a tool maker.

There are very successful businesses that operate using poor tools. They may not be run as well as they should be, but good results can, and often do, come from bad tools. Also remember, though, that eliminating your three symptoms will likely make the company even more effective, especially in the long term.

Answer 2

High dev turnover is a symptom, not a cause. The cause is bad management. If those businesses prosper, it's usually in the short term and usually precedes a buyout, a merger, or an outright failure. I've seen it happen over and over.