Law of Unintended Consequences Jamis 20 Oct 2005

16 comments Latest by Jamis Buck

I was reading “Path of Daggers” by Robert Jordan tonight and came across a reference to the Law of Unintended Consequences. Googling for it turns up an entire host of references, but I like the way Jordan phrased it best:

Whether or not what you do has the effect you want, it will have three at least that you never expected, and one of those usually unpleasant.

Of course this can apply to anything, but it certainly rings true in software development, and especially in software maintenance. As software evolves, it will inevitably grow. No matter how humble it starts, there will be new features, or security problems, or whatever, leading to greater and greater complexity. And as the complexity grows, so does the opportunity for unintended consequences.

Entire disciplines have cropped up, solely dedicated to mitigating these consequences. Test driven development in particular has saved me numerous times from some potentially catastrophic failures. (Ironically, because TDD only tests specifically-stated assumptions, it has also failed to save me a few times, too, but that’s a topic for another day.)

16 comments so far (Jump to latest)

Benvolio 21 Oct 05

I’m so addicted to Robert Jordan. I was lucky enough to get my hands on a pre-release copy here in Australia and couldn’t put it down for 3 days straighht until I finished it.

I think the ‘Law of Unintended Consequences’ had a huge effect on the two major projects I had due that week.

Benvolio 21 Oct 05

I’m so addicted to Robert Jordan. I was lucky enough to get my hands on a pre-release copy here in Australia and couldn’t put it down for 3 days straighht until I finished it.

I think Robert Jordan and the ‘Law of Unintended Consequences’ had a huge effect on the two major projects I had due that week… but I’m not sure my customers would consider that a good excuse ;)

Dr_God 21 Oct 05

Books #9 and #10 have the unintended consequence of making you wish you had read anything - anything at all - except those books. :|

Splashman 21 Oct 05

Jamis, your URLs are breaking the page layout.

Also, is it just me, or has the body text size increased?

Anonymous Coward 21 Oct 05

body text size increased

Moritz 21 Oct 05

The Markdown (or whatever syntax you are using) plugin is deactivated. Thus, the text is not rendered in HTML code.

Ryan Tomayko 21 Oct 05

Holy crap, I love WoT. Jamis, let me know if you want to club on the Jordan books sometime. I’ve found they’re infinitely better when you have someone to talk to about all the crazy stuff that happens. A friend introduced me to them when I lived in Columbus and now that I’ve moved they aren’t nearly as enjoyable.

Do you read George R.R. Martin’s “A Song of Ice and Fire” by chance? Those books are amazing.

(btw, check out the domain name in my URL)

Doug 21 Oct 05

Since somebody else already commented on a recent design change, I’ll chime in with my pet peeve.

Why don’t links appear in a different color than non-link text?

The first thing I do with any new browser is to uncheck the “Underline Links” button. Most sites use visual cues (such as text color) to make it clear where the links are. Adding underline, IMO, is superfluous and makes the text look busy.

However, since I know that most people either like the underlines (or don’t ever bother to change *any* preferences), I’ll accept that this is a personal preference.

If a site, such as SvN, decides that it prefers to use only underlines as visual cues for links, then it should be sure to enforce this using its stylesheet.

Doug

p.s. I note that the front page of 37signals.com uses both colored text and stylesheet-added underlines for links.

Mark Gallagher 21 Oct 05

From my experience, the number of “unintended consequences” from a change to a web app is a function of the complexity of your user base (and the amount of change).

When we started our intranet (big bank), it was primarily used by technical people in Chicago (like us). We made enhancements based on what we thought made sense and most worked out great. With mergers and growing use of the tool, it was later used by over 100,000 employees all over the world. Now we were getting unexpected feedback - words having different meaning to employees of our merger partner or new employees with very limited web experience struggling with common web page functions.

We changed our process to put out prototypes to a more diverse group of employees to try to capture the unexpected earlier in the process.

Good discussion. Mark

Jordan Roher 21 Oct 05

Nice URL, Ryan. Second only to the Dark One, eh?

I’m a huge Wheel of Time fan myself - that’s the next major fantasy series I’d pay anything to see movie’d in LOTR/Harry Potter style.

pwb 21 Oct 05

Another major advantage of doing “less” is less chance of unintended consequences.

Carlos 21 Oct 05

Jamis,

I have a question in reference to your comment on TDD (Test Driven Development).

I listened to the 37Signals podcast the other day about 37Signals’ methodology when creating applications and Jason mentioned to “spend as much time {working} in the UI as possible.”

It’s possible that I don’t understand the phenomenon of TDD, but isn’t TDD in contrary to Jason’s rule of spending as much time as possible working on the UI?

How much importance is placed on TDD in the 37Signals’ shop?

Fazal Majid 22 Oct 05

You are completely behind the times. “Knife of Dreams” has been out in bookstores for over a week now.

Jamis Buck 22 Oct 05

Carlos, no development is possible, TDD or otherwise, unless you have idea of what your goal is. That’s what the UI mockups that Jason and Ryan provide are all about. They are a physical embodiment of the application’s requirements. The UI then drives the unit tests, which define how the code needs to behave in order to produce the UI.

Other shops might provide a novel-length document describing the requirements, but I know the UI mockups are much easier for me (at least) to grok at a glance than a 200-page document. Either way, though, you’ve got to somehow define what your application *is* before you can begin describing its behavior in unit tests.