Do programmers need good people skills? No, they don't. Sure, it helps, and you need at least some people on the development side of things who can speak to the business types, but a programmer generally doesn't have customer contact. If a sales rep has poor people skills, he needs to find another career. If a programmer has poor people skills, he won't do quite as well as one who does. Programmers are near the bottom of the barrel as far as need for people skills.
Constant communication with business isn't needed. Even agile methods revolve around an iterate-and-test methodology. Developers are developers because they see how the pieces fit together. The communication has to happen at the level of drawing out good business requirements. The BRD is not perfect. If I can make assumptions like that, I may as well design a new development methodology that starts with "assume all code is bug-free". The best thing to show to a client to get feedback is a working prototype, but you need to establish boundaries and procedures. You need to say "this is what we're doing next, are you certain these features are things you want to try out"? Then they can come back and revise after they see how they work out.
Has my view changed with experience? Once, I thought I should just listen to what the business side was asking for. Now I realize that all I need is a sound proof room, a car battery and some wires attached to sponges, and I can get them to tell me what they actually need, rather than their poorly thought out idea of how it should be accomplished.
Customer relations? Do programmers require good human relation skills when dealing with customers (I want to challenge the moms-basement cowboy programmer that "can do anything")?
Yes, they do because they need to work as a team and understand the customer to a certain degree. Even though the traditional view of the programmer sitting in the back-room turning out code still purveys, but more organizations are strapped for people, so programmers need at least some level of understanding customers. In my organization, programmers don't meet customers, but they certainly do have their say when requirements are drafted. A second note is that most programmers must collaborate with teammates. Poor human skills make that difficult.
Is constant communication to business required for developers (when doing a project)? Take into consideration the UML and BRD's are perfect.
depends on the urgency of the project. I have worked on projects which had no interaction with business and projects which have constant. Cant really say which way is better, but i like it when my team is left alone to work instead of being micro-managed.
Has your view changed with experience?
Yes. It changes with every project, every success and every failure.
The skills a programmer needs depends very much on the environment and, in particular, the size of the project and the company - and the size is for me the more critical factor.
Generally speaking the smaller the team the more you need to be a generalist. Once you get to a project team of 5 or 6 you might be able to absorb one or two specialists, however with a team that size the chances of you having to address something outside your core competence increases. I'm not talking about consistently moving from pillar to post, more that as individuals are on leave, sick or just plain busy, the project may need you to fill a gap which doesn't necessarily sit within your specialisation.
If you're in a project team of 20 or more then you can absolutely specialise and indeed at that size it's probably optimal if 80% or so of the team are focused on specific skills with the remaining 20% filling the cracks.
The numbers apply (at slightly increased levels) to companies too. Generally smaller companies will need people to be more generalist.
I'm development manager in a company of 20-odd (mostly technical). Right now I wouldn't recruit anyone who I wasn't comfortable interacting with clients either to gather basic requirements or do issue analysis.
The way work ebbs and flows means that there are going to be weeks when there isn't enough hardcore development (that is taking specs and turning them into code, as opposed to writing specs, doing support or whatever) to keep all the developers busy.
At that point trying to juggle a resource schedule in which people have constraints beyond their technical specialities (our technology stack is necessarily fairly broad so this is unavoidable) is one constraint too many.
We're now arriving at the size where that will start to change and once we hit 30 people I'd imagine we'll have far more flexibility to recruit specialists but if you want to work in a smaller company soft skills are likely to be very desirable, if not critical.
But even beyond that overall I would suggest that the wider array of skills you have, even at a basic level, the more useful you potentially are to your team and your company.
You don't need to be able to do everything but sometimes there's a rather wilful "I'm not interested in doing that so won't". If you want to take that approach that's fine but don't be surprised when some decent opportunities are closed off to you because someone isn't willing to work around you.
What I also find interesting is that in my experience most of the best programmers really don't have the "typical" programmer mindset (for which read antisocial nerd with no social skills) and are very capable of dealing with people. I'd suggest that part of the reason they are amongst the best programmers is because they can do this as much as it is their technical skills.
I don't think anyone can be labelled an excellent programmer who doesn't have people skills. If you can't interact with the client (internal or external) you build the wrong thing. Doesn't matter how well it works or what it does or how "Elegant" it is, if it doesn't serve the client's needs.
A developer who doesn't spend time dealing with and observing users of software will build bad software. If you don't understand the abilities of those who use the software or the way they think, you can't build an effective interface. I've seen lots of crappy interfaces where the developers thought they had done something really cool, but the users were just lost. If you don't spend time dealing with users and understand their needs, how can you decide how to test beyond unit testing (assuming you work somewhere without a dedicated testing team).
The people who are paying the tab have a right to be kept up-to-speed during the process. Yes most of this is done by the PM, but there are times when you must be able to describe the issue to him or her so that he can pass it on to the client. You often have to be able to express a problems in terms that a non-techincal person can understand.
You have to be able to inteact with the business analyst in order to clarify a requirement. You have to be able to interact with your team members and boss. I've seen these kinds of programmers, too. They alawys think their solution is best and wreak havoc on the code base as they change everything everyone else does and no one wants to work with them. Usually they aren't nearly as good as they think they are because they are so sure they are right, they don't consider other possibilities.
To be considered excellent, you have to be able to go beyond what everyone else does. To be recognized as excellent and given higher and higher responsibilities, you have to consider office politics. No one in the business world in any profession can get by without people skills if they want to be considered excellent at their jobs. No one.
The goal of a business, by my personal definition, is to make money in the long term, including external costs. Developers should be judged by their long term contribution to that goal.
If that doesn't sit well, there are other choices; start working for a non-profit organization, writing open source code, or living on a commune.
Developers who interact with people need to have a minimum amount of ability to work with others; that generally means all of us. If their work is so outstanding that you can ignore regular social gaffes, that's a tradeoff worth making. If their cowboy coding costs you in maintainability later, that's not a gain, that's a delayed cost.
On any relatively complex product, you're never going to have perfect requirements, and someone's going to need to interact with users (or salespeople) and work with them to nail down the requirements. Otherwise, you're going to have to go back and fix what you guessed wrong on after the fact, and the gain from speed-to-market may be lost on a very slow release 2.
The more complex the product, the worse the requirements, and the greater the need for developers to have social skills enough to work with people who aren't developers. The more complex the product, the larger the number of developers, and the greater the need for those developers to write code that doesn't impact other developers.