The Law of Conservation of Complexity

February 14, 2012

When I was a wee pup working on My Yahoo, this was a crime I committed more than once. We’d argue about how a particular feature should work, narrow things down to two contradictory options, and end up implementing both as a “configurable setting.” Users would then never find or use the setting, and we’d end up looking like idiots when we had to remove it in a future release.

In our defense, we often did this because how users “used to use the product” was very different from “how they were going to use the product.” So we’d design things so that they would work one way for “old” users who migrated into the new product, but a different way for new users who just started using it. This worked well until we wanted to update one (or both) versions of the feature, and then had to find a way to manage the dependency. More often than not, we would end up migrating “old” users to the “new” setting, removing the setting, and then moving people forward. So rather than avoid pissing off the “old” users, we just deferred annoying them to a later date. It would have been better to just place a bet on the “new” approach, and be ready to modify it if the benefit to the business (gaining new users) didn’t outweigh the cost (pissing off old users).