Making mistakes: Django startproject and Rails new

I like to see how software reacts when I step off the happy path and make a mistake. Today I found this interesting difference with an unknown (or misspelled) command line option: “–derp”:

$ django-admin startproject –derp myapp
usage: django-admin startproject [-h] [–template TEMPLATE]
[–extension EXTENSIONS] [–name FILES]
[–version] [-v {0,1,2,3}]
[–settings SETTINGS]
[–pythonpath PYTHONPATH] [–traceback]
[–no-color]
name [directory]
django-admin startproject: error: unrecognized arguments: –derp
$ rails new –derp myapp
create
create README.md
create Rakefile
create .ruby-version
create config.ru
create .gitignore
create Gemfile
(etc.)
view raw rails new hosted with ❤ by GitHub

An interesting difference! Personally, Django is reacting like I’d expect. And so for me it’s following the principle of least astonishment. Rails, on the other hand, doesn’t give any indication that it didn’t understand the –derp instruction. It simply goes ahead and creates myapp. I see it as producing a false negative (whereas Django delivered a true positive).

False negatives and false positives is a really interesting area in medical testing as well as software development. Consensus seems to be that false negatives are the more severe problem:

False negatives … are given when the test case passes, but there is in fact a bug present in the system and/or the functionality is not working as it should.
Though both are an annoyance, it’s safe to say that a false negative is more damaging than a false positive, as it creates a false sense of security.

Paul C, Watching Out for False Positives and False Negatives in Software Testing

Leave a Comment