Why Transition Developers

If your software development organization is planning a major shift in development methodologies, many of your developer's technical skills will become instantly outdated . We are often asked by managers anticipating an organizational transition whether they should retrain their developers or simply hire new ones. A hint to our answer can be found in the ordering of the parts of this book, People, Processes, and Technology . While technical skills are very important to developer performance, mature processes and developer's business skills and personal skills can play a bigger role. New technical skills, given an individual's sound computer science background, can be easily taught. Business skills, including knowledge of corporate culture, the company's business processes, and domain knowledge can take years to develop. Personal skills, such as dedication, flexibility, and leadership are usually established early in one's career and are not at all likely to be taught. Our answer, therefore, is a resounding yes. Software development technology is constantly changing and healthy organizations should be continually looking for opportunities to transition developers to newer development technologies and methodologies.

Established IT organizations do not typically make a wholesale change in their technology overnight. This makes it easier to transition development organizations on a piecemeal basis. Before switching to a new technology, organizations typically pilot the technology on a prototype or small project. After gaining some experience with the technology, a strategic decision may be made to start employing that technology on new projects. It typically does not make sense to make major changes to a development methodology or underlying technology midstream in a project. Even after all ongoing projects have been completed and all new development is being done with a new technology, legacy software must still be maintained . Here is how we map the technology life cycle of an IT organization to the mix of developers in the group .

In any software development organization, there is likely to be some developers who are "early adopters" of technology. These are the individuals we target to become part of new pilot projects whenever a technology transition is being considered . We are often asked how to spot these early adopters. Generally, it is fairly simple. Every mainframe development group probably had one or more developers who experimented with web browsers during the early days of the web in 1994 and 1995. Maybe they did this on their home PC, or maybe they took a class at the local college. We look for these or other signs of interest in a new technology when selecting developers to pilot a new technology on the job. As these developers gain experience in the technology, they can then move on to become the design leads and mentors for other developers as new projects with the technology are started.

Having formal training processes in place to allow developers to be trained on new technologies is also a key factor to successfully transitioning developers. Many times, new technologies such as Java are adopted with such speed that traditional training organizations within a company cannot keep pace with the changes. This is where creative approaches can be useful:

Consider using local university extension programs to supplement your in-house training.
Partner with hardware and software vendors , or integrators, to obtain training resources.
Use job rotations to place developers within other organizations that are already using the technology you wish to adopt.
Create virtual teams of experts within the organization to share best practices on a new technology and train their peers.

An example of the latter approach is the Java ACES (Action-oriented Community of Expertise in Sales) group with Sun's field system engineering (SE) organization. As Sun prepared to publicly announce the Java platform in early 1995, Gary Oing, manager of the SE programs office recognized that the normal field training infrastructure could not possible train the entire SE organization in time to support the initial Java technology rollout. It was then that the Java ACES program was founded. The Java ACES were a small group of about 50 SEs who received special training in Java technology and then actively spread this knowledge about the entire field SE organization. Specifically, software development in Java was one of the key focus areas of the Java ACES. The program was so successful that it has continued as the Java platform evolves and has launched similar programs in other fast-moving technology areas such as High Performance Computing (HPC) and data storage systems.

In a large software development organization, you will undoubtedly find some developers who are resistant to developing new skills in order to transition to a new technology. You shouldn't expect or force every developer to transition. Sometimes a developer's knowledge of legacy (or soon to be legacy) systems is so valuable to the business that management would never think of letting that person go. Its important to remember that not all developers need transition to a new technology when it starts being introduced into an organization.

During a transition period, you may also want to consider using consultants to augment your internal staff. At the start of a project, consultants can help train your developers and help out in critical areas where you have not developed a critical mass of trained staff. One of the transition mistakes you should be careful to avoid when using consultants is having them take the lead role in the implementation of a new technology without involving and training your own staff. What we have seen happen many times is a development organization that decides to implement a new applications architecture or technology: they don't have the training staff to do this internally, so they go off and hire consultants to do the first project. The consultants complete the first project while the internal staff continues working on their existing projects. At the end of this cycle, your organization is no closer to having transitioned the development team than they were at the start. To address this issue, we recommend having at least a one-to-one ratio between your internal staff and consultants on any transition project. In addition, be sure to budget for at least a twenty percent overhead for consultants to complete on-the-job training.

At the tail end of an organizational transition, you might want to consider outsourcing any remaining development or maintenance of legacy applications. Outsourcing maintenance is perhaps a riskier proposition if the majority of the application knowledge base stays with your organization and transitions onto new projects. The remainder of this chapter examines some of the issues that arise when transitioning developers to new application architectures, programming languages, or development methodologies.