Pair Programming and course correction
I listened to this episode of Troubleshooting Agile recently, and they were discussing early course-correction. And it made me think of the ways that many people in companies write software. If you work in iterations or sprints, then you are hopefully showing your work to a customer or product owner at least once every sprint. Why do we do this? Because it gives a chance to look at our progress, and to change direction if we need to. Of course, it’s even better if we can have these conversations on a more frequent basis. Every conversation with a stakeholder gives us a chance to correct our course. Now, many people like to program solo, and then have their work peer-reviewed. This, along with feature branches, is a model that works really well with open source software, allowing strangers to contribute to an open source codebase. But it does mean that the peer review is the first time to course-correct. If something is seriously wrong with the design or the implementation,