Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Many new team leaders are compelled to organize their own team’s work based on the experience they got when they were programmers. Sometimes, the lack of alternative viewpoints or simply a negative past experience leads to the usage of a “trial and error method” and that, undoubtedly, is a very expensive approach in any industry. In this article, I list several rules I’ve acquired with my experience; they help me manage my team of developers and projects we work on together.
When a former developer becomes a team leader (I mean that he or she possesses a team to manage, not merely a title), additional duties arise. The duties are from the management realm and even some bright and clever programmers are not acquainted with them prior to their starting to carry them out. There is no know-how in the article, although it may prompt a leader to consider ideas it describes or find an alternative approach. The advice is placed without any order of preference or importance.
1. Log Your Self
You’re not an independent developer anymore. You’re not a player in a jazz band where the art of improvising is a measure of your skills. A part of your duties is to be able to tell the project’s current and coming tasks and what each of the team’s developers is doing now. Write down all such records, as in in a chess game where every turn is recorded. This is a rule I fought against most when I became a team leader. My project manager was a pretty inquisitive person (from my point of view), and he came and asked me a few times a week what each of my team members was doing. On the face of it, I found it very disturbing and even annoying because my approach was that the project manager had to communicate to the team leader and not to go deeper.
Now, I see that he was right, (Ezra, many thanks to you!) All his demands finally made my administrative work brighter and clearer for myself. I became able to estimate the quality of my colleagues’ work on a more precise level and they started looking at my requests with greater responsibility. Scrawling a plan on a slip is not enough for a manager, although it might be suitable for a sole developer. Ask your programmers once in a while to update the status of their tasks and you’ll always possess a very up-to-date status of the project. Besides that, separate all your tasks into several groups (features, bug-fixing, research, improvement, and so on) and when a task is originated, assign one of them. It makes the whole picture easier to understand, and when a task is completed, add a coming release number of the project to trace when the task was finished. This facilitates composing an update/history report from release to release.
If your OS is Windows-based, a handy tool is MSOutlook. Its standard Task has a category field, or you may create your own form. There are dozens of free issue-task-bug tracking systems, among which I can list old good Bugzilla and Scarab (see the Resources section for links).
2. Explore Open-Source Projects
Sourceforge, the biggest open-source project (OPS) portal, reports about 60,000 such projects it’s holding and about 600,000 programmers from all over the world participating in those projects. Some of the projects are extremely stable, robust, reliable, and are being used in a production environment. Many of them have the kind of license that allows their usage in commercial products. They’re very useful when you develop a non-unique task. Every time you make a new request for a module, node, or functionality, try to figure out whether something similar is done by a community. First, you’ll gain in development time and second, an OSP is usually being developed faster then yours. Its bugs are found and fixed quicker and new features are introduced more actively.
Lack of such knowledge leads to re-inventing the wheel and the wheel sometimes isn’t as round as one wished. When you find a project that looks suitable for your needs, pay attention to its pulse, namely, how much it’s alive—send a simple question to its mailing list and see how fast you get a response. Also, find out about its competitors and analyze all pros and cons. Sometimes, the number of similar projects may be pretty big and such research takes time, but you’ll be generously repaid for your work. This rule applies most of all to developers and not managers. But, when you’re entitled to choose approaches and technologies to accomplish a target, it affects you as a manager to a greater extent.
3. Work in a Sandbox
Put your project in a version control system (VCS), create a working directory on your local disk, and don’t allow anybody to work outside of the sandbox. Force your team members to update the code frequently. For a big feature or refactoring that can’t be integrated into the working trunk on a daily basis, create a separate branch and work from it. Don’t allow any code to be just-on-your-local-disk. Create a system of naming your releases and don’t grudge labels (or in some systems, they’re called tags). Write a set of automated scripts that do all the job on their own. I like the idea of nightly builds—a scheduled procedure building a product version out of the latest source. My projects are built and deployed automatically during the night so anyone can work with the most current version of the product. Add supplementary server scripts (if your VCS system allows) that help you check code policy on every commit and alert you by mail in a certain case.
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
Create a system of unit and functional tests. For every public method, except for very trivial ones, create a unit test-set of checking calls for the function with regular and sabotage parameters. Check that test results for both cases are correct or processed expectedly. When a feature or certain functionality is finished, write a functional test that checks not only the function as a unit test does but all the way from the front-end to the end and back. Run the test several times with valid and wrong parameters and check that the system manages calls properly. When a bug is found, first add a test that crashes on the bug and only then fix it. When the project grows, the unit and functional test will grow also; every new bug will get its own “chain,” preventing it from appearing in the future. Run all the tests as part of the nightly builds, thus making outgoing versions more reliable and more tested.
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).
Summary
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.
Resources
- The old good Bugzilla—http://bugzilla.mozilla.org,
and Scarab—http://scarab.tigris.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 Author
Roman 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 roman@rytov.com.
