Process Consensus
Managing a product is hard work. Managing a product with a large codebase is harder. Managing a product with a large codebase and dozens of developers across a half dozen teams is madness unless you have a common process. However, too much process gets in the way of what many think of as the real work of programming. How do you strike a balance? What process is helpful, and what becomes just a burden? To start answering this question, we must ask a few more targeted questions. Why do we want a common process? What does the process provide? How can we let the process deviate over time or between teams to fit different needs? By asking and answering these questions, we can start to find a place for common work strategies without slowing down the act of coding too much. Before we go on, though I should say that reducing the speed of coding isn't always a net negative. In fact, as with any scientific endeavor, deliberate action is usually preferable to slapdash chaos. While