|
||||||||||||||||||||||||||||||||||
| NN/g Home |
||||||||||||||||||||||||||||||||||
Ask Tog, September, 1998The Complexity ParadoxMy friend Harry Vertelney recently reminded me of Larry Tesler's law of Conservation of Complexity. Simply put, one cannot reduce the complexity of a task. One can only shift the burden. Harry draws the relative complexity among the user's, application programmer's, and OS programmer's domain thusly: What's wrong with this picture?If the original browsers shifted so much complexity toward the user, why were those original pages so easy to use? For the same reason that computers, in the late 1970s, were easy to use even though they heaped almost all complexity on the users: Neither one really did anything, so there wasn't much complexity involved. 2nd Order EffectsIn that landmark book, Tog on Software Design, I presented Tog's Law of Commuting: "The time of a commute is fixed. Only the distance is variable." Translation? People will strive to experience an equal or increasing level of complexity in their lives no matter what is done to reduce it. Make the roads faster, and people will invariably move further away. Bottom LineGiven that people will continue to want the same level of complexity in their lives, given that we will continue to reduce the proportion of complexity of any given function that we expose to the user, we may expect that the difficulty and complexity of our own tasks, be they at the application or OS level, will only increase over time. That has certainly been the case so far--we've gone from simple memo writers and sketchpads to document processors and PhotoShop. And we may assume that's only the beginning. -Tog |
|
|||||||||||||||||||||||||||||||||
|
| | ||||||||||||||||||||||||||||||||