Training By Bug Fixing
Sticky?
It is always the same problem. You need more staff to deal with an increased workload, you take on X new developers. It can take months for those developers to get up to speed and many precious man hours of your existing developer's time to hand hold them through their first steps, productivity plumits. Typical 'Tar Pit' scenario.
Stick To Standards
Luckily with more and more standards being used in software development,
and development style settling down,
you can indoctrinate new starters more and more easily.
The latest IDEs and documentation tools make it easy to browse source code and the power of desktop machines means that even some very large applications will happily run on a modern PC.
But that still leaves the business
The Bug Branch
My latest idea in this area is the Bug Branch which uses a branch of the project source code with deliberately re-introduced bugs. The concept is that an experienced developer looks back through the bug tracking database and re-introduces a number of bugs for each subsystem into the new branch of the system and creates a set of hints for the one or more new starters. The new starters then need to find the requirements, look at the design and source, make a change, build, test and deploy the system. And in doing so learn about where to find the documentation, how to use the development environment, configuration management and what the system is supposed to do.
The key concept is that they were real bugs and required a real fix. Each member of your existing team will have knowledge of one or more of these repeated mistakes and so should be able to quickly guide new starters in the right direction (all should know not to fix it for them). The hints given to the new starters would be in the form of a starting point and a document or team member to query about it.
What bug to re-introduce depends on the type of system, but here are some suggestions:
- Contradictory requirements (if you had any)
- Build script problems
- Simple design mistakes (not too complex)
- Omitted required implementations
- Typos
- Mistakes in test suites
- Configuration mismatches
What a waste of effort! You might say. Which would be true, it is a waste of effort. But I don't think it would be pointless. Making a new starter relive the recent experiences of the team and making them use the tools and the environment in a structured way provides a number of benefits:
- You can induct a number of developers at the same time.
- You build personal contact with the existing team through shared experiences and focused communication.
- You introduce all the tools through your process and in your environment.
- You can cover a wider scope than just the subsystem the developer is intended for.
- You can verify the skills of your new developer and see indications competence, confidence and speed.
- The new developers can propose alternative solutions using their external experience that may be adopted.
