Ranty McSputterpants (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} wtfwtf_ok) wrote,@ 2007-04-23 10:14:00 |
|
eponymous "laws"
I found a page of adages named after people on wikipedia. I love these, and now have more at my disposal.
There are two self-referential laws: Hofstadter's Law, which is well known to me as I'm a software engineer; and Stigler's Law, which is new to me, but not that useful in my everyday life.
I have a law of my own:
- Any sufficiently confusing feature is indistinguishable from a bug.
I suppose this is a version of the K.I.S.S principle, but it goes a little beyond that. When developing software (or hardware!), obviously one has to keep in mind the engineering realities going on behind the scenes, but one should also continually keep in mind the mental model that the user will construct as to how the software works. This mental model is simple and may be no deeper than a connection between a button onscreen and a result. The point is that if something was done because of engineering realities, it must also make sense in the user's mental model of how things work. If it doesn't, you will get bug reports. This is most notable in "missing features", when a useful feature is omitted because it would run too slowly or because it could open things up to abuse (in a multi-user system). The user does not know why the feature was omitted, and their mental model of the software suggests that it would be an easy thing to add, so they helpfully suggest it be added.
I found a page of adages named after people on wikipedia. I love these, and now have more at my disposal.
There are two self-referential laws: Hofstadter's Law, which is well known to me as I'm a software engineer; and Stigler's Law, which is new to me, but not that useful in my everyday life.
I have a law of my own:
- Any sufficiently confusing feature is indistinguishable from a bug.
I suppose this is a version of the K.I.S.S principle, but it goes a little beyond that. When developing software (or hardware!), obviously one has to keep in mind the engineering realities going on behind the scenes, but one should also continually keep in mind the mental model that the user will construct as to how the software works. This mental model is simple and may be no deeper than a connection between a button onscreen and a result. The point is that if something was done because of engineering realities, it must also make sense in the user's mental model of how things work. If it doesn't, you will get bug reports. This is most notable in "missing features", when a useful feature is omitted because it would run too slowly or because it could open things up to abuse (in a multi-user system). The user does not know why the feature was omitted, and their mental model of the software suggests that it would be an easy thing to add, so they helpfully suggest it be added.
