Okay, you've got a slightly different problem here. You need to encourage a culture of communication and idea-bouncing.
It may help to encourage a discussion area where the team can asked stylistic questions and learn from each other's experiences.
In one of my previous "lives," we held these during lunches, called these "brown bags," and kept them very informal. It took some time to get everyone on board, but eventually, we were all learning from each other and the resulting code because more consistent. You could still tell each person's style from their bits, but you could also see where the discussions had made a difference.
I forget who said it, but one of the classics on software development practices notes that it takes ~18 months for an organization to move up a level in the Software Maturity Model. The same source also notes that each level must be met. This means it'll take roughly six years to move from a Level 1 organization to a Level 5 (world-class) organization.
It may also help to ensure that each resource has time for research. Personally, I like to allocate 15-20% of my time to that, for if I'm not allowed to try things out, I can never learn new things except by experimenting with them in production code--which is a bad thing.
Also, leave room for some disagreement and try to find the compromises.
--f | [reply] |
Ovid, it's a fair point:
I agree with your point in general but footpad below makes some good ones too: There is a difference between a coding style making sense to one person and it making sense to a group of people who have, in essence, to peer-review the code when it needs updating.
Bob, for example, is dead wrong unless there is an extremely compelling reason for using them: Some data structures just lend themselves to certain ways of doing things. Pseudohashes are, as you say, experimental and from what many have said to me, not the greatest tool in the world. In business situations it pays to code defensively.
Ultimately, though, settling issues like that should be (IMHO!) by coder fiat: If your manager is a coder (mine was) and there is a dispute, they rule on it. Otherwise the most senior/competent coder (alpha geek ;-) rules on the issue, which, I guess ultimately leads to a coding standard, sigh.
I certainly agree that life is different for small and large businesses: Where I worked (and will hopefully be working again this summer) is going through the transition phase.
Cheers, Elgon | [reply] |
