Why you should write buggy software with as few features as possible (no, really!)

This is the title of a presentation by Brian Granger at last month’s SciPy2013 meeting (see also last week’s post). Now, I certainly concur that software should not be feature rich, but the idea that it should be buggy as well got my attention. Why would anyone want to delivery software that is buggy? Brian described how his experience on writing IPython Notebook. IPython itself is an interactive shell for Python. Notebook, recently introduced, is intended to provide an accessible interface to IPython for the non-specialist.

Brian emphasized the need to remain focused on delivering a useful product, regardless of the budget (even if you have $1 milllion to play with). The problem with adding features is the hidden costs arising from increased complexity of code: development takes longer and programmers may need to specialize, testing will need to be done on multiple platforms, and the users may find complex features hard to learn (“cognitive load”), and so on.

Notebook was kept simple, and features were kept to a minimum: no multi-user or multi-directory features, no security model, and so on. Now, the developers decided to exclude these features by design, and have declined so far to meet user requests to include them. Some features, such as an XML Notebook format and a database backend, turned out to be nightmares to maintain, were or will be removed. Brian pointed out that the developers did not answer a crucial question: what is the simplest Notebook we can deploy that will be useful.

So why are bugs helpful? Well, it means that the software is in wide use – and actually provides a metric on market penetration. The bugs can tell you how users are using the software, and can drive improvements in software. They can also attract new developers, which may be crucial in Open Source projects. Now, loads of bugs are bad, as Brian points out, but some bugs can be turned to a project’s advantage. He cited a list of annoying jumping scroll bugs that have not been fixed because doing so would cause the user experience to break down: understanding these bugs actually helps the developers design an effective solution.

Finally, Brian pointed out that features are a cultural matter: it is hard to say no to people, and developers may damage a working community.  The solution? Define the scope of the project, implement a minimal set of features that satisfy this scope, don’t worry about bugs and learn to use them to your advantage  – but make sure that the there are no bugs that will prevent users doing useful work.

The talk made me think of feature bloat in Microsoft Word and other word processors. Would we all be happier if in fact they still only handled the important tasks that met the bulk of our processing needs, and did not try to be all singing and all dancing?

Finally, this demo video on Notebook may prove interesting (but the music is annoying – I turned the volume down):

I wish to thank Ray Plante for recommending this talk.

Advertisements
This entry was posted in computer videos, computing videos, education, informatics, information sharing, Internet, Open Access, programming, social networking, software engineering, software maintenance, software sustainability, user communities and tagged , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s