Summary
Authors: Granger, Brian, Cal Poly San Luis Obispo
Track: General
Everyone knows that in software, features are good and bugs are bad. If this is the case, then it must follow that the best software will have the most features and the fewest bugs. In this talk I will try to convince you that this is a horrible way of thinking about software, especially in the context of open source projects. To accomplish this goal, I will use the development of the IPython Notebook as a case study in software engineering. I will describe what we learned in our numerous missteps, what we did right and how the eventual success of the IPython Notebook radically changed how I view software development. This will clarify why feature and complexity creep need to be actively guarded against and how a well defined scope can help in that battle. I will propose an informal framework for evaluating new feature requests and discuss the social/community aspects of saying no to new features within a project. Finally, I will try to convince you that bugs are a sign of quality software and a healthy community. If I am successful, you will want to go home and write buggy software with as few features as possible.