Does team size impact code quality?
-
Is it true that more developers means more complexity? Is there an ideal number of developers for a team? What can we learn from this? Let’s find out!
Team sizes > 0 have much better code quality
-
Is it true that more developers means more complexity? Is there an ideal number of developers for a team? What can we learn from this? Let’s find out!
Team sizes > 0 have much better code quality
Bigger teams require better management. And here in most cases is where everything fails. Most managers can't even manage themselves so nothing good can be expected out of there. If you have a good project and team manager you'll have more rules, better and well implemented code quality check tools and better and more automated processes. Overall a better structure to comply to, resulting on an implicitly enforced coding standards. For project management, the more monkeys you have the better you have to break tasks and plan dependencies. And always: - never build a team of geniuses or nothing ever will be finished - never build a team of freshly out of school people or nothing will ever work Always try to build an heterogeneous team with a couple of creative people not more, experienced people that deliver and fresh meat to just type text. Cheers! :)
-
Is it true that more developers means more complexity? Is there an ideal number of developers for a team? What can we learn from this? Let’s find out!
Team sizes > 0 have much better code quality
Kent Sharkey wrote:
Is there an ideal number of developers
1!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
Bigger teams require better management. And here in most cases is where everything fails. Most managers can't even manage themselves so nothing good can be expected out of there. If you have a good project and team manager you'll have more rules, better and well implemented code quality check tools and better and more automated processes. Overall a better structure to comply to, resulting on an implicitly enforced coding standards. For project management, the more monkeys you have the better you have to break tasks and plan dependencies. And always: - never build a team of geniuses or nothing ever will be finished - never build a team of freshly out of school people or nothing will ever work Always try to build an heterogeneous team with a couple of creative people not more, experienced people that deliver and fresh meat to just type text. Cheers! :)
:thumbsup::thumbsup:
Life is all about share and care... public class Life : ICareable,IShareable { // implements yours... }
-
Is it true that more developers means more complexity? Is there an ideal number of developers for a team? What can we learn from this? Let’s find out!
Team sizes > 0 have much better code quality
Kent Sharkey wrote:
Team sizes > 0 have much better code quality
I don't know, a team if 0 produces 0 bugs. (Admittedly, it may not be the most productive team).
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Kent Sharkey wrote:
Is there an ideal number of developers
1!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
Agree! But that also varies.. :)
Don't mind those people who say you're not HOT. At least you know you're COOL. I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
-
Kent Sharkey wrote:
Is there an ideal number of developers
1!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
Bigger teams require better management. And here in most cases is where everything fails. Most managers can't even manage themselves so nothing good can be expected out of there. If you have a good project and team manager you'll have more rules, better and well implemented code quality check tools and better and more automated processes. Overall a better structure to comply to, resulting on an implicitly enforced coding standards. For project management, the more monkeys you have the better you have to break tasks and plan dependencies. And always: - never build a team of geniuses or nothing ever will be finished - never build a team of freshly out of school people or nothing will ever work Always try to build an heterogeneous team with a couple of creative people not more, experienced people that deliver and fresh meat to just type text. Cheers! :)
AlexCode wrote:
Most managers can't even manage themselves so nothing good can be expected out of there.
Very good summary of the entire problem.
-
Kent Sharkey wrote:
Is there an ideal number of developers
1!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
This answer is so elegant that it is often overlooked. This way there is no way to confuse who is responsible for the bad code and the good code too. Eliminates confusion.
-
Is it true that more developers means more complexity? Is there an ideal number of developers for a team? What can we learn from this? Let’s find out!
Team sizes > 0 have much better code quality
I have always preferred working alone... and maybe everyone else has preferred not working with me? Hmmm... :~ Anyway, when beginning a new project, one probably shouldn't look at a spec and decide "this will require ten developers" and then go hire ten developers. Start with one developer to get things going, set the style, then bring in another, etc. Build the team slowly, and only as needed. The only large team I was on (dozens of developers), was for a project that was well into maintenance.
You'll never get very far if all you do is follow instructions.
