This post originated from an RSS feed registered with Ruby Buzz
by James Britt.
Original Post: Simplicity
Feed Title: James Britt: Ruby Development
Feed URL: http://feeds.feedburner.com/JamesBritt-Home
Feed Description: James Britt: Playing with better toys
Reading through a recent crop of posts on xml-dev, I came across one from Bill de hÓra. The topic was ambiguity in specs (specifically, the W3C recommendation on XML namespaces), and de hÓra was speaking about problems with relying on implicit reasoning.
Being able to reason conveniently about the consequences is a useful operational definition of simplicity. Implicitness gets in the way of that by leaving to much to the imagination.
This seems a very good yardstick to apply when considering adding or changing some feature, whether it be in a language spec or application or what have you. You should ask yourself what the side-effects of some action may be, and also consider if some set of random people (albeit familiar with the domain) would give the same answers.
If you cannot easily describe the consequences, and feel confident that most others would describe them the same way, then you are probably introducing complexity.
Note that differing expectations of consequences is a problem regardless of who is right. Even if the actual consequences are simple, a perception among enough people to the contrary is probably a Bad Thing. If users are uncomfortable with some option, they will avoid it, or implement workarounds and hacks for behavior that will never actually happen. Or, perhaps worse, they will not take sufficient precautions for a potentially troublesome action.