Part of the problem we encounter when trying to implement a new policy, procedure, or even software architecture is that the people making the rules are seldom the ones that have to live with the consequences. That is not the case with the Ratcheting project. We are all, first and foremost, programmers here and will very much feel the pain of eating our own dogfood. That being said, it is in our best interest to ensure Ratcheting really does provide quality and does not end up burdening our fellow developers.
As we continue to define and refine exactly what Ratcheting is, an idea of how it might be used starts to emerge. Here is what a developer's workflow might look like during her day-to-day activities.
- A developer is ready to commit code changes to the repository
- The project is built and unit tests are run*
- Calculate check-in risk locally*
- Static quality analysis is executed*
- Review risk and quality report
- Improve code based on report guidelines
- Re-run check-in script
- A risky commit will be flagged by the build radiator
- A code review will then be generated automatically
- The code review is assigned randomly to a person who has modified the file recently
- Make improvements based on code review feedback
Most of the things on this list we are already doing anyway, the addition of Ratcheting provides rapid feedback of code quality and risk around the time of commit, not during a post-mortem of the project done long after the project has been completed.