Five To-Dos for a Fledgling Java Team Leader, Page 2
4. Define Project Rules
This rule is about defining definitions (sorry for the tautology). As the leader of your team, you are responsible for the code from any point of view. It starts from a code style your team has agreed upon to follow and ends up with the names of features, nodes, and technical terms your command members use when communicating with each other. I'm familiar with stories where a manager describing his point doesn't know for sure how the matter he's talking about is named. Insist on strong and even documented definitions of common project terms as the official internal language in the team (I got this practice from Yair Altman and found it extremely useful).
Sometimes, misunderstanding leads to very disappointing results (as when two different things are called by the same name or even not called by a certain name at all and a developer implements a feature for an unexpected node). Regarding a code style, the point is standardizing. Define a single accepted standard that all of your developers will be obliged to follow. If your VCS system allows you add a preprocessing script on the server, write one that not only reformats the code according to the style but also makes additional checks (for example, checking the appearance of System.out in the code). Another idea is to define a header of any text file in the project; it should report the author of the file, creation date, modification date, and a revision number. It gives you a possibility to analyze the origin of the code on the production site (in case of a problem investigation).
5. Put Bugs into Irons
The idea of testing your code usually meets opponents among people never tried it in practice. They claim test writing is just a waste of time, but if you analyze how much time is spent re-fixing bugs or re-coordinating correlations between different developers (or even teams), you'll see that you gain much more than just profit in time; the amount of grind, unskilled labor, and definitely double work, will lessen significantly. Some go farther and plan all their design process based on test writing preceding code writing. They create the casing for future functionality that insures against unexpected changes in it (see TDD in the Resources section).
The advice I listed above is not inventions and for some it may look like there's nothing that has added value, but I saw a few teams and projects suffering from the lack of any replacement of such rules and in my own experience I found them very effective. I hope they'll help others as well.
- The old good Bugzilla—http://bugzilla.mozilla.org,
List of such systems with reviews: http://www.stickyminds.com/tools.asp
- The biggest portal: Sourceforge (http://www.sourceforge.net),
Java OSPs: Apache Jakarta (http://jakarta.apache.org)
- The famous VCS—CVS (http://www.cvshome.org);
a CVS competitor: (http://subversion.tigris.org).
General Software Configuration Management patterns: (http://www.cmcrossroads.com/bradapp/acme)
- Java code style. Java code style formatter Jalopy (http://jalopy.sourceforge.net) has lots of useful links on the realm
- Testing: JUnit framework (http://www.junit.org)
JMeter—Java load-test framework (http://jakarta.apache.org/jmeter)
About the AuthorRoman Rytov has over 7 years of programming, design, and leadership experience. He holds a server team leader position at Entopia Inc (www.entopia.com). Roman and his wife Lia have three children (Valeria, Victoria and Gabriel) and live in Israel. You may contact Roman at firstname.lastname@example.org.
Page 2 of 2