Features and Scope in Open Courseware

This post originally appeared on the Software Carpentry website.

A couple of weeks ago, Brian Granger (one of the core developers of IPython) posted some thoughts on features and scope in open source software. In it, he enumerates some of the risks associated with constantly adding new features to a piece of software (open source or otherwise):

1. Additional complexity in the code base (which makes future work more difficult).
2. Increased "surface area" for bugs (the more features there are, the more places a bug might be lurking).
3. Increased documentation and support time.
4. It forces developers to specialize, which makes "big picture" thinking harder.
5. Increased testing effort.
6. A more complex user experience. (Microsoft Word, anyone?)
7. Opportunity costs: time spent working on X is time not spent working on Y.

He then enumerates some things projects can do to throttle growth down to manageable levels:

1. Explicitly list things that are not going to be implemented, i.e., define a limited scope for the project.
2. Make features fight hard to be accepted and implemented by telling the community that the default answer is "no".
3. Separate feature requests from other issues.
4. Discuss costs and liabilities as well as benefits whenever a new feature is proposed.
5. Be willing to remove things.

He also lists some questions projects can ask:

1. What fraction of your user base will use the feature, and how often?
2. Can it be added as a plugin?
3. How difficult will it be to test, debug, document, and maintain the feature, and what fraction of your development team is capable or interested in doing this work?
4. Can you implement the functionality in a more limited, but much simpler manner?

Everything Brian says applies directly to open courseware like Software Carpentry. People constantly suggest new topics that could be added to our material, but few of them say, "...and I'll write it," and more often than not, the topics are things that would interest only a fraction of scientists. We have therefore been cutting back on material rather than expanding it: as useful as Make, object-oriented programming, image manipulation, and disciplined use of spreadsheets are, they just aren't useful enough to justify expenditure of our scarcest resource—time.