You're six-feet, 190 pounds and can type System.out.println faster than most people can say AJAX. You're a person who dreams about the Milwaukee Brewers winning the World Series and the correct data structure to be used when talking about a baseball player. You've spent five years of your life writing Java code and leading Java development teams. You consider yourself an expert in Swing, Struts, XML, and XSL-FO and feel comfortable talking about any other buzzword in the Java world such as JSF, Portal, and AJAX. You've had experience as development lead on a team with anywhere from three to seven people where Java applications were rolled into production well within the scheduled deadline. Now you have received a management position on an internal Java development team. Where do you start? What things do you look at from day one? What's your role going to be as a manager? What would you like to see happen within your team? Do you want to keep your technical skills? How do you rate your employees at the end of the year?

These are just some of the question's that you'll have to answer.

Fortunately, I'm the Brewers fan who just got a new first-line management position. The team that I'm managing consists of 18 employees with skillsets ranging from Java Swing development to J2EE Web development. The main point of our existence is to create, support, fix and build tools inside IBM for a number of platforms. A number of small tools have already been developed that use Swing technology for the front-end. The small tools end up communicating with DB2 systems on the back-end and start a number of native back-end processes depending on the back-end servers' platform. The team has also created a Web application that lets internal developers create a fix pack of a particular product. These are examples of just a couple of the many Java tools that my department is responsible for.

Now back to the questions at hand. Where does a manager start when taking over a Java development team? These are just a couple of the things that concerned me when coming in as manager of a Java development team.

Who's Doing What?
Every manager has to understand what the main responsibility of the team is. Once that's understood then the next question to answer is, who is working on achieving that goal. What positions have been defined in the department to carry out the team's primary responsibility? For instance, do you have developers working on a single application from the beginning to end or do you have each software development process task broken down among different employees. Once you understand the tasks that everyone is working on, does it matter how they're done? For example, the team that I'm managing has application owners who are responsible for the entire development process lifecycle for a particular application. An application owner would have to gather the new requirements that come in, create a design that fits into the existing application design, develop, unit test, and do the production test. And if an external customer discovers a problem with the tool it's their responsibility to fix it.

Some things I've heard from the group is that testing all our small tools is quite expensive. Every small tool is dependent on each other. New functionality added to one of them may have an impact on another, thus causing all application owners to test their code before it's released.

From a resource perspective this really scares me. You wouldn't like your most experienced developers spending a lot of time on testing. Some would disagree with me on this and say that this person has the application domain experience and should be involved in production testing. However, I feel that testing something like this should be documented in a test plan and tested by a separate group. Test cases could be written by this separate group cross-referencing the requirements. That way a different set of eyes could manually test the application outside of the application owners who should only do unit testing.

Is There a Development Process?
As the manager of any software department I would hope so. Hardcore software developers hate processes. I know this from past experience. When I was given an assignment, I wanted to complete it as fast as I could by writing code. If you wanted to know my progress all you had to do was ask. I felt the information in my head was sufficient. However, this kind of thinking makes things very hard when working on a team that's larger than one person. Information has to be communicated from one person to another. The memory of what someone said lasts only so long. Having documentation helps remind an employee of what's required. It helps for reviews and lets an employee hand his work off if something happens and he's pulled from the project.

Without a development process it's even harder to rate employee performance. Who is your best designer? Who is your best coder? By defining a development process, the strengths and weaknesses of each employee can be measured at particular stages of the development process. Running a tool suite that does metrics throughout a development process can be used to measure performance. Tracking and monitoring this kind of information will also help you understand the task force needed for a particular project. For instance, if a manager knows how long it took for an application to be finished with a particular number of employees, it makes it easier to estimate how long it will take those employees on the next project.

The team that I've inherited has an ad hoc development process. There's no standardized format of what's required in each development phase. For instance, Team A could have a requirements document that looks different from Team B's requirements document. Does something like this need to be standardized throughout the development process? Some would argue that as long as there's documentation for each development stage it shouldn't matter. They'd also argue that the format of each document should be up to the project lead. However, if you have employees switching from one team to another, this may become an issue. It may take an employee some time to understand a format that's different from what they used in a prior project. From a management perspective it's always nice to standardize the format in a tool that can run some kind of metrics. For example, if a requirements document is submitted with a tool, metrics could be run on how good the document actually is. When a review is held for the requirements document, the number of problems found in the requirements document could be traced and analyzed by a manager. This could be a perfect way to isolate the employees who have strong requirements-gathering skills. As a manager, I feel it's a priority to make sure our development team has a standardized format for all development process milestones.

Are Swing Applications Old?
First of all why would a manager even care about Swing applications? As long as the development lead knows when to change from Swing to a more Web-centric application, why should a manager even care? The reason I ask this is that you have to remember I come from a technical background. I feel that if a strategic decision has to be made on which technology we should use, I'd like to be part of it. If I were the type of manager who thought Swing was something for my two-year-old son then of course you wouldn't want me in the discussion at all.

We have a number of Swing-based applications that are used by our internal customers and by administration. The Swing-based applications follow a fix process required by every internal developer who wants to create a fix. This fix process is very complicated and requires an internal developer to run a number of the Swing applications so a fix can be created, tested and deployed to external customers. There have been a number of developers who have implemented additional functionality within the Swing applications. Over time, this has made some of the code hard to read. There is logic that is duplicated because a developer was not aware of particular methods that already existed. There are also a number of classes that were implemented that do not fit within the old design because of the changing functionality. Instead of enhancing the old design, now a new design and old design exist within the application. This, of course, has nothing to do with the debate over whether Swing-based applications are old but does create additional work if you were to migrate the applications from Swing to a Web-based tool. Time would have to be spent to understand the differences between the old design and new design. Eventually, a design bringing both of them together would have to be created.