Individual practices in team setting

There are certain programming practices that work when done at an individual level but need careful application (and probably ceremony) when working in a team.

For example, pulling out small domain classes for things like Money, Range, Link, etc is a good idea. I'm used to doing that in my day-to-day programming... problem is that my team mates have the same good habits. So after a while, you may run into more than one class representing the same thing. If a concept is tied to your project's domain, it is very likely to have an impact on various features (user stories), and hence, different team members may end up having to implement that same concept. If folks do not realize that a class for the concept is already implemented, they may accidentally add more copies of the class. In my current project, we had Link, ServiceLink, and Url almost doing the same thing until we noticed the duplication and made all consumers use just Link.

One way to deal with such problems is to have well-known project conventions, especially around packages (or folder locations for Ruby). With package understanding in place, developers will need to look up classes in the corresponding package before adding a new one, just in case someone else has already added a similar class.

A similar problem occurs with inner classes (perhaps small helper classes, UI beans, etc) that you don't see a use for beyond the containing class. You think that if you need a similar implementation somewhere else in the future, you'll promote the inner class to an outer one at that point of time. However, it may be that in the team, you're not the one who encounters such a scenario, but your team mate does, and he or she won't know about the inner class you made. This may again lead to duplication of classes.

To prevent such occurrences, inner classes should generally be avoided, just so that it is easier to locate and reuse them.

Of course, an effective and generic way to deal with such issues is to pair furiously (perhaps rotate pairs everyday) so that you have very good knowledge of the code base, and are most likely party to creating/modifying most classes anyway. The hope is then that you'll remember what you've seen before.

This is where Agile practices such pair programming and collective code ownership help.

Tags: technology:agile, technology:thoughtworks, technology:experiences Last modified 13:42 Wed, 6 May 2009 by AmanKing. Accessed 196 times Children What Links Here Share Except where expressly noted, this work is licensed under a Creative Commons License.