Sponsored Link •
Bill Venners: What does orthogonality mean and why is it good?
Andy Hunt: The basic idea of orthogonality is that things that are not related conceptually should not be related in the system. Parts of the architecture that really have nothing to do with the other, such as the database and the UI, should not need to be changed together. A change to one should not cause a change to the other. Unfortunately, we've seen systems throughout our careers where that's not the case.
Dave Thomas: For example, when one client changed the number of lines on the screen, they had to change the database schema too.
Andy Hunt: This is what computer scientists call coupling, one thing is tied—or coupled—to another. There are exceptions and tradeoffs, but in most cases you want to minimize coupling between things that are otherwise unrelated. It is easy in an OO system to accidentally introduce coupling. You can do it just by the way you set up libraries, if you're working in a language like C or C++, where you link things together. If you want to make a little program to test out one API or interface and you have to link in every library in the system, you have too much coupling. Your system is not orthogonal.
Orthogonality is one of those creeping viral problems. If you introduce some new functionality and you realize you've coupled it to something unnecessarily, you might say, "These two things shouldn't really know about each other, but it's OK. It's just these two things." But the next functionality you add might also know about something it shouldn't. Soon you have four things that know about each other that shouldn't. The problem grows somewhat unexpectedly. You get a system that quickly becomes a nightmare. One way we illustrate a highly coupled system in the book is the helicopter story.
Bill Venners: I thought the helicopter story was a great illustration. Why don't you tell it?
Dave Thomas: A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.
It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you're constantly dancing on all the controls to keep the helicopter stable.
That's kind of similar to code. We've all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you'll always get that kind of distributed bug fixing.
The funny thing about the helicopter story is that I'm not a helicopter pilot. When I wrote the helicopter story, I wanted to make sure it was accurate. I knew of a USENET group on helicopters, so I posted the helicopter story saying, "This is what I'm intending to write about how helicopter controls work. Is it correct? A helicopter pilot emailed me and said, "I read what you wrote about controlling helicopters. I didn't sleep all night."
Come back Monday, March 17 for Part III of this conversation with Pragmatic Programmers Andy Hunt and Dave Thomas. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Andy Hunt and Dave Thomas are authors of The Pragmatic Programmer, which is available on Amazon.com at:
The Pragmatic Programmer's home page is here:
Dave Thomas was not the first person I've interviewed who mentioned the arcade
game Whack-a-Mole. James Gosling also called upon the versatile Whack-a-Mole
metaphor while pointing out that it is sometimes hard in
engineering to know if you've solved a problem or moved it:
The Agile Manifesto is here:
Ward's Wiki, the first WikiWikiWeb, created by Ward Cunningham, is here: