Errors Become Features

Also known as Development by Prototype Generalization.

Source

Generalization -- An Alternative to Error Messages, pp98-99, Western Educational Conf Proceedings 1984. -- DickBotting

Description

In many cases a programmer writes an error message into a program because they don't know what to do with the a particular state or case. When the program is used then the user can often tell the programmer what to do with that special case or state. The programmer can then remove the error reporting and put in code that implements a now obvious UserStory/Function/UseCase/Feature.

Example

I (DickBotting) had an error message "File not found" in a simple text editor I was writing. After getting it myself twice with a new file, I recoded the program to help the user create a suitable template file.

In the same project, users were asked to input a line number to edit (this was 1984, right), but they tended to input a string instead: Error: That is not a line number! Feature: search the window the user is looking at for the string and pretend that that is the line they wanted. Error: String not found. Feature: Search whole file and output message:

I guess you want this line:
Error: String not found. Feature: This user needs help, so provide it.

Consequences

It is a fun way to program but you have to admit that you are less than perfect.

Related Patterns

YouArentGonnaNeedIt stops you adding features until they are asked for.

ErrorsBecomeFeatures gives you a stop-gap until you do need it.


We also have BugsBecomeFeatures?. In other words, we had a bug that allowed some new useful thing, so it became a feature. Sometimes we call it FeatureBug?


See also LavaCode, SideEffect, NineteenEightyFour.


EditText of this page (last edited November 13, 2014) or FindPage with title or text search