I think we quite agree programming must be more boring than programmers are able to manage (specially when you leave them alone). Even more if there are coding guidelines.
What do you think about having a supervisor profile in a small team?
Have you managed to avoid this figure? Maybe it is not possible so the effort is for nothing.
Please, share your experiences
I worked in a team a couple years ago and we did not have one. In retrospect, I think it would have really helped to have one, especially in the beginning when we assembled the team, because everybody coded in their own style to some extend, even though we had coding guidelines in place.
I think that it would have been beneficial for the team and the project as a whole if we had had one person supervising the whole code and not just bits and pieces.
Some teams need someone to check code. But a better way to do this, other than having one person responsible for all the code, is to have frequent coe reviews. Those teams are often "bigs" or in a company that have some years and really need to have people keep consistent code.
Some teams don't need someone to check code. Those kind of team are often the killer programmers in a tiny team, often in a startup. After all, that's what you produce in the end that is important, you'll need to make sure the code is right AFTER the application works...
As a software CTO, I think it is very important. It appears that sycronizing development practicing as well as coding conventions is important. If you don't, the code looks as a product of bunch of disagreeing pirates. It becomes difficult to maintain, people become "territorial", and the code quality decreases.
I believe there are both advantages and disadvantages with a code supervisor.
In a well working team, you need to trust all the programmers that they do what they are suppose to do. Having a code supervisor reviewing all your code or look over your shoulder may create a lot of problems in a psychological state.
In the other hand, it's generally stated that in a project group, there are always people slacking. Therefor, in some groups, it might be necessary for the quality of the code, to have a supervisor reviewing it.
If it hurts the group by having a supervisor, call it something else and just have a person responsible for the quality of the code. This person do not need to review all the code or watch over the shoulder for the programmer, he can just be there as a knowledge source.
I like to believe that people do their best and that you need to trust the individuals in the group. Unfortunately it is not very common that that is the scenario.
And for the record, programming is always fun!
I was always such a "supervisor" person. Not because someone told me to be, but it's just in me.
I believe that all developers try to give their very best. And as we all agree on standards, everyone trys to keep them. Still it even happens to myself that I am sloppy or forget to do some refactorings, etc. So some kind of supervision is necessary. Such supervision should be automatic.
Although team mates tend to get annoyed by getting reminded to keep to the standards, in the end everyone is happy if the product works and the code looks good in the end. There has to be someone, people can ask, if they are in doubt. Also someone has to be responsible for the automated checks of conventions. And someone must drive the discussion of conventions. Someone must remind people that it's bad if daily build failed.
It's important that conventions are discussed in the team and then fixed when agreed on. They can be changed later, but they need to be fixed. Even on a two person team, both developers must have the same understanding how code has to look like, where files have to go in SVN, how stuff is named, which techologies to use, and so on.
Adding a supervisor from outside, e.g. company policy, on top of a team will not work. If the "supervisor" is on the team, and just drives the team to define and keep the conventions, the whole team will be responsible. Usually this will be some senior developer, as avoiding typical bug patterns or keeping to the architecture are also part of conventions.
There are many tasks a supervisor would have to do. Maybe these tasks could be distributed to people who care. All this tasks will NOT be done if requested. If you ask your boss "I could fix these conventions or deliver the functionality" he well always chose the later, so you have to care about it. IMHO Caring is the most important.
I think team size is less relevant than project size. If a small team works on a single project for 2 years, the code base will be large and I think you need someone to co-ordinate things to ensure quality. On the other hand a small team working on shorter projects (thus generating less code) probably need less supervision. But I think in either situation a code supervisor would just be the senior developer or team lead etc.