"You don't need to wory about UI designs, portability, comprehensive error checking. You may be developing something that sits pretty much on your desk or has a limited audience. "

I disagree, well sort of.....

In most cases these days there is often not much more to do from a "modelling" perspective - that is to say in most traditional asset classes (but not all) the models are well developed and well understood from a numerical/math perspective. It is easy to obtain information on how to price something fairly standard (including a lot of common exotic/hybrid structures). The challeges that face quants starting in the bigger houses these days lies more on analytics - clean, efficient library implementations that allow faster pricing with greater stability/consistency accross product variations where there are only minor incremental differences. This is largely a programming  problem, especially in instances where firms are trying to re-factor and consolidate their analytics across the asset classes into a unified library with an efficient code base that heavily promotes OO, re-use blah blah blah...

For a long time now quant groups have supported independant business areas - these days however they are becoming increasingly centralised into an independant cost centre that is charged out to business units. Now they are more central there is more control over library development from a strategic perspective so a lot of software engineering principles/controls on development are being enforced minimising the duplication of effort and thus the development time. Within these quant teams there are usually plenty of guys who have been around for 5-10 years who understand the models and products extremely well (relative to a junior coming in), what they lack is the software development skills hence when making junior hires it's important for them to find someone who knows math/finance well enough to understand the models, but more importantly (in some cases) is a good programmer who can take existing models and create new efficient implementations consistent with the strategic principles governing an organisations analytics development. This is another reason why there is less of a strong requirement for a PhD these days. They no longer need guys to push the envelope with innovative ideas on the modelling side, what is needed is guys who can understand and implement. In many areas, from a "modelling" point of view the challenges lie more in good calibration than they do in "core" model ideas.