I think a lot of it has to do with how flexible a person feels he wants to be in a certain job. It has to do with arrogance a bit too. I would never walk into a job and demand that things be done my way or I'd walk. I would expect to adapt to the requirements of the position and the needs of the projects. If I felt an established piece of technology could be done better a different way, I might mention it, but face it: the company's already spent X dollars building the technology that way in the first place, and it works. They're not going to be receptive to rebuilding it just because I have an itch to see it work differently, even if the new way might be better. It's not worth it.

It also has a lot to do with what the developer wants out of a job. If their ideal job is working 100% with the tools they like with free reign to do things how they think things should be done, the only way that's going to happen is if they get into a small company as The Man for that type of work. In large companies with a large amount of existing staffing, he'd better adapt to the way that company does things or find another job. Not every job is desirable to every person.

When I started at my current position, all I did was Perl stuff. I've had my share of projects, and I learned a lot with each one. In some projects I had carte blanche to design and implement. With others, I came in mid-project or with a very fixed design, so I had to work with what I had and adapt. I had no problem with this. Others might. I recently transferred out of that group and my current position involves no Perl whatsoever, since this is more of a systems/operation group and any maintainence scripts I write would be unmaintainable by the rest of the staff. I'm still learning a lot and I code Perl in my free time. I like what I do and have no problem working under the constraints imposed by the position, by the existing staff, by the organization or by the systems and architecture we support.

Even if I were in a management position, where I could dictate how things would be built, what technologies we would use, I would certainly not go out there and demand that everything be re-written to my specifications. I might suggest that developers move towards certain technologies and standards for future projects, but there are all kinds of additional things to consider here, and they all boil down to one: money. It is not cost-effective to re-build all of our applications just because I think module A is better than module B (even though it may be, perhaps it wasn't when this stuff was built).

If you find yourself with a job where all of your desires can be met as far as the development environment goes, consider yourself lucky, and if you really are this rigid, for God's sake don't quit!

David