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 teh custome 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 liekly 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 thinkyou willget 8 hors a day in determining your deadline, yo already have either a deadline that will not be met or willbe askingyour 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, es[pcially 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 teh devs are given to work from and you will find yourself pushing releases that work but don't do what is needed ruiniong your credibility.

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.