Don't rotate.
I don't think anyone gains anything from the position being rotated (apart from the ones that don't deserve to be the lead might get more money than they are currently receiving).
Having a brilliant lead developer who can do the following, does wonders for the development process:.
- Knows how to delegate.
- Is in control.
- Is an experienced developer.
He's a single source for the rest of the team to look up to and seek advice from. He's also the mediator between higher-level management and the core development team. I don't know of any managerial team that likes dealing with change (unless they're the ones instigating it).
If you really are the best suited for the position, everyone would know that. Everyone would know that (e.g. higher-level management, your teammate, etc.). State that you don't believe rotating the position is worthwhile (if you believe so). Then sit back and let them do the appointing - refrain from name-dropping or any sort of self promotion as this would make you look unprofessional
I hate having support teams and development teams.
When this happens the developers start to look down on the support people (it is a less glamorous role). People get tagged as suppport and then can't get back to doing development where the better pay and promotions tend to be.
Additionally the development team doesn't feel the pain of their mistakes (which is critical to getting better!) and tends to do the same things repeatedly that the support team ends up fixing. This ends up with them thinking they are great developers (they never hear otherwise) and the support team thinking they are idiots.
The other disadvantage is that the orginal developer can often find and fix a bug in a complex system faster than a support person who has to get up-to-speed on what was done and why before fixing. Further, I have often seen support people break things more because they didn't understand the why of something in the first place. This is especially true when you have developers who just do what they are asked to do without questioning it or pushing back on a bad requirement. So when the customer asks for something that conflicts with another requirement they don't know about because they didn't work in that part of the system, the change is made and something that used to work doesn't any more. It's true this can happen when the original development staff does support as well but is less likely to becasue they have more of the backgroupnd information internalized.
I don't see the problem as being how to minimize admin time for developers but more how to get them to do the needed admin work at all! I do think that in planning work, you should only plan for 6 hours a day of productive time. You need to account for leave, jury duty, admin work, meetings, etc., and if you think you will get 8 hours a day in determining your deadline, you already have either a deadline that will not be met or will be asking your people to work continous overtime or not allowing them the time off they need to have to recharge. A tired developer is an inefficient developer. Don't plan to force people to work exhausted.
I do suggest that if your application is database centric, you should have several database developers (not DBAs but people who write database centered code and design databases, especially people with performance tuning knowledge). Your application will work better if you have these people from the start in the design phase. You will also want to read about database refactoring and set up a process where database changes can properly be made as needed.
A contract GUI designer is nice to have around as well. This kind of designer is often not needed full-time, but it's handy to have someone you know you can hire when a major redesign of the user interface is being done.
A good business analyst is a must. A bad one can destroy a project and the team. Do not keep a bad analyst for longer than you need to process the paperwork to fire him. This person can do more harm to a project than virtually anyone else. He will add months and years to projects trying to work around the garbage the devs are given to work from and you will find yourself pushing releases that work but don't do what is needed ruining your credibility.
Best Answer
Some quick thoughts:
Also, it's always worth going and (re)reading the Agile Manifesto, and especially the twelve principles.