This article continues on from my prior article Improving Computer Science Degrees for Software Developers on the topic of better methods of developing expertise as software developers in the work place. The original inspiration for these articles is the post Master Craftsman Teams by Robert C. Martin in which he proposed a formalized development path based on the apprentice – journeyman – master craftsman model used by the trades. The specific inspiration for this article is use of rotations in the field of medicine in training medical students, interns, and residents. Trainees spend a fixed period of time working in a particular specialization (e.g. neurology) or unit (e.g. intensive care), after which they rotate into a new assignment.
Benefits of Rotations
The use of rotations provides two key benefits:
- Rapid learning: People learn most rapidly when placed into new, unfamiliar situations, as opposed to being in the same environment year after year. The initial ramp-up period for new team members often corresponds to the period of increased learning, after which it tapers down. The use of rotations essentially maintains this ramp-up state to realize this enhanced learning on a more ongoing basis.
- Breadth of experience: Rotation assignments are specifically selected to provide a broad range of experience in the field. This helps trainees determine what they would like to specialize in, and once specialized helps them work more effectively with other specializations. Breadth of experience helps develop that "big picture" understanding of the field and provides better appreciation for how each specialization contributes to it.
While software development is quite a different field from medicine, I believe that the use of rotations is just as beneficial to developing expertise as developers. One example is spending time maintaining or enhancing a preexisting code base tends to teach the importance of having cleanly design and easily understood code – in other words maintainability. Another more general example is developing that breadth of experience tends to provide a better appreciation of the importance of context in determining what development technologies, practices, and methodologies to apply.
Required Rotations
What kinds of rotations would be beneficial for developers? Listed below are the key assignments that I feel every developer should experience:
- Production Support: Keep an operational system running. This develops your ability to diagnose and fix problems. It teaches you about all the bizarre events that can happen in a real system that never seem to happen in testing. I personally found it humbling to watch systems I thought were solid get hammered and fail in ways I never expected. You will learn the value of many non-functional requirements such as reliability, performance, scalability, manageability, and supportability (e.g. good logging).
- Maintenance: Make enhancements and fixes to an existing code base in active use. You should do this both for a system you originally developed and one you have not. This teaches the importance of good design and readable code – i.e. maintainability.
- End-User Support: Directly dealing with user inquiries and problems. This is enlightening in numerous ways: it provides you with a better understanding of what users value, how they react, their level of understanding of I.T., and what they like and do not like in the software they are using.
- New Development: Develop a piece of software going through all the stages of the software development life cycle: inception, requirements, design, coding, testing, release, and maintenance. Going through the entire cycle gives you a deeper understanding of the big picture. More importantly, you will have the opportunity to benefit from feedback in later stages regarding earlier stages: e.g. coding indicates requirements were poorly understood by all, or testing reveals a design defect.
Optional Rotations
There are many other possible rotations across the full breadth of the field of software development. A large (but not complete) list of these assignments is provided below, organized into categories.
- Assignments in different types of software development organizations:
- Product-focused
- Service-focused (e.g. consulting)
- Internal I.T.
- Assignments in different organizational cultures:
- Bureaucratic
- Entrepreneurial (e.g. a start-up)
- Lean
- Assignments using different development methodologies:
- Agile (process-light)
- RUP (process-heavy)
- Waterfall
- Chaotic
- Assignments working on different types of software systems:
- Web applications
- Enterprise systems (e.g. messaging, batch processing, integration of systems)
- Desktop
- Mobile
- Games
- Software development tools (e.g. compilers, IDEs)
- Software infrastructure (e.g. operating systems, databases, networking)
- Scientific (e.g. simulations)
- Mission critical (e.g. medical, aviation)
- Assignments involving different software development skills:
- Web design (html, CSS)
- User interface design
- Database design
- Database administration
- Data conversion
- Web services
- Batch processing
Obviously you cannot gain experience in all of the items listed above. The point is to think about where you want to take your career as a software developer and then choose assignments that provide sufficient breadth while avoiding irrelevant assignments.
Adopting Rotations
How can rotations for software developers be adopted? As much as I think it makes sense, I do not see the I.T. industry as a whole formally adopting rotations in a fashion similar to medicine. So what about at the level of an individual organization? Even fairly small companies usually have different teams or products for which rotations could be formally set up. I have seen companies doing this for undesirable work such as customer support or production support. Developers are rotated into such roles either for an entire iteration or for a certain percentage of days each month. But the focus of these rotations is typically on getting the undesirable work done rather than the increased learning.
In many companies I have seen a tendency for developers to get stuck into a particular role or team. Supervisors are reluctant to give up a trained, skilled resource to another team, even in a trade. Temporary assignments on another team are also fairly rare for the same reasons plus the common fear by the supervisor that the temporary situation ends up becoming permanent. So a developer who wants a change often needs to initiate it by changing jobs.
Since the industry as a whole as well as individual organizations cannot be relied upon to provide for rotations, I believe it becomes the responsibility of each individual software developer to seek out that breadth of experience. Formal rotations may be beyond our control, but we can explicitly seek out different assignments to provide that breadth of experience and accelerated learning.
I'm interested in hearing what you think. Do you agree with my list of required rotations? Are there any you would add or remove? Do you have examples of where you actually used rotations? Let me know by leaving a comment below.