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
Re:An underlying malaise?
scrottie on 2009-11-06T19:50:28
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.)
