Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)

scrottie
  scott@slowass.net
http://slowass.net/

My email address is scott@slowass.net. Spam me harder! *moan*

Journal of scrottie (4167)

Thursday October 29, 2009
06:10 PM

Growing the team from small to medium sized

[ #39820 ]

A few things have to change as a software team grows.

Your code organization system might be entirely logical to you, but that might be because you were there when it was written. Do the module names re-use the same few words over and over? "Manager", "Handler", "Master", "Server", etc are commonly overused, meaningless identifiers but any over-used words is a symptom of the same problem: meaningless names. New programmers will have to do archeology with grep to figure out how the thing is put together. Re-using the name of the company in multiple parts of the module path to somehow distinguish two parallel code hierarchies similarly creates confusion rather than organization. If a module lacks a meaningful name, it lacks a clear distinction for what goes in there as opposed to somewhere else. Also, the module names will start to sound like Monty Python's "Spam" skit. "Oh, did you mean to edit Data Manager Manager Manager Data Manager or Manager Manager Data Manager Manager Data Manager?".

Using a chat channel is generally a good idea. However, if new programmers are supposed to draw on the entire dev team for help rather than having any sort of per-project or general mentoring system, you have a lot of broadcast overhead. You also put each programmer in an awkward position of deciding at what point to finally step and help rather than hoping another has more time and knowledge of the matter.

There's a whole code standards thing. This combines with the organization problem. A new organization system will develop for each new programmer's limited understanding of the existing organization system. More broadly, are future programmers going to be even more bogged down? And what's going to be the priority then?

-scott

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I don't know the exact details of the situation you describe, but in situations I have experienced that exhibit similar indicators, there has been a fear to rewrite/refactor. One of the syptoms of this has been the error of enforced duplication by "doing it right from here on in" (which for some reason, some people seem to think can be done effectivly without altering existing code ). Could it be that the codebase is growing brittle and the need to increase the team could be a symptom of a problem rather th
    • There is a fear to re-do anything, but it's a little bit different than that. When things reach a point where no one cares any more and my non-disclosure won't be a noose, I'll write about it...

      Yes, growing the team is a symptom.

      Thank you for your comments...

      -scott

  • The number one thing to realize is that an average team of 5-7 people has a throughput that matches a team of 20 people. So there is a big productivity drop chasm that you don't want to stumble into by accident.

    If you need a cite, read Software Estimation by Steve McConnell. (I forget where in the book the tidbit is, but the whole book is good so you should read it anyways.)