Since I hold the job of both coder and designer I wonder if a lot of others are in the same boat. What percentage of your time is each?
For me it's as close to 50/50 as you can get and I think I do a pretty good job at each: RPMWare. That said, I know I'm neither the best coder or designer out there, but I can hold my own in each respect.
Is the best team one with full-time designer and full-time coders, or a hodge-podge of guys (and gals) who wear both hats.
You actually have two questions here.
My own answer to that is a firm that depends. Bigger shops tend to realize economies of scale which favors specialization. Smaller shops tend to go for the lower communication overhead by having each person fill both roles. Your hiring requirements need to be adjusted depending on which way you go.
What is the optimum mix? That depends on what phase of development you're in. When working on a bug fix release, you're spending more time coding than designing. When working of a feature enhancement release, you're spending more time designing than coding.
Actually, you left one role out. A lot of shops don't have proper analysts. They tend to use their SMEs as analysts which is a recipe for failure unless they just luck out and get SMEs who have good analytical skills too. So, your developers are probably having to fill that role too.
I find that the best teams are small ones that swap responsibilities. I've found myself to be at my most efficient when working alongside three to five other developers as we design, model, code and test software. It's a great system as all members of the team spur each other on throughout the process and ensure that we are all on task.
Of course, this all depends on the size of the team. If you're in a large software shop then I'm sure that members will fit one role and specialise in that role.
Unless you're managing a very large group of people I would always recommend sharing each task out and working on a bit together. Most software development methodologies support this way of creating a software product and you'll find that the earlier stages of Requirements Gathering and Analysis are much easier when handled by a group.
Many seem to argue that you should specialise staff that are experts at one thing; I would go as far as to argue that they shouldn't be the one doing it, only part of the whole equation. At least with this guy/girl at your side then the rest of the team can benefit, allowing every member to know who is good at what and where to go for advice/help. In a way it is mentoring for the entire team.
For me, there seems to be very little reason to specialise your team UNLESS you're managing too many people to work on multiple stages. Even then I would look into swapping people around in different roles during this time, creating a mix of the two styles.
Chances are, a good generalist won't quite be able to do the same quality job a specialist in that given area could do. At the same time, having too many specialists on staff can be a problem, because a lack of common understanding on a given topic may not allow them to collaborate as fluidly as they'd like. A team should be a combination of generalists and specialists.
That being said, I think people are too eager to draw the line between 'coding' and 'design.' They might use different tools, and take wildly different approaches to problem, but at the end of the day, they're both making decisions about how a program should work, and if a team can't realize the importance of how these two 'disciplines' interact, the end product won't be as strong.
Perhaps a "Lead Programmer" spends more time at the highest levels coding interfaces and defining classes, and a "Follow Programmer" fleshes out more of the code bodies, but really, design and programming are the same activity performed at different abstract levels, and a good programmer thinks in multiple levels at the same time.
I have seen many attempts to structure and manage software development. In my opinion, most non-agile methodologies produce excessive amounts of waste. If you split software into design versus programming, what is the data that the designer passes to the programmer? If that data can only be read by a human, then it is wasteful, subject to misunderstanding, and expensive to maintain.
If the designer provides formal details, it is part of the code, and you might as well call it programming. If the designer can't program, then the programmer becomes the designer. If the programmer can't design, you've got a big problem.