TITLE: The Grand Complications of Software AUTHOR: Eugene Wallingford DATE: May 28, 2015 2:11 PM DESC: ----- BODY: Yesterday, Sean Heber made a suggestion drawn, I imagine, from Apple's foray into the world of watchmaking:
I propose we adopt the watch term "complications" for all software features.
It turns out that, in the world of horology, complication is a technical term:
In horology, the study of clocks and watches, a complication refers to any feature in a timepiece beyond the simple display of hours and minutes. A timepiece indicating only hours and minutes is otherwise known as a simple movement.
I don't know if Heber was writing tongue in cheek, but "complication" is certainly a term that programmers can appreciate. In software, we value functions, classes, modules, and even whole systems that do only one thing but do it well. This is sometimes referred to as the single responsibility principle, which engenders a separation of concerns and leads to software that is easier to modify and maintain. Simple movement is one of the defining elements that make up of the the Unix philosophy:
Write programs that do one thing and do it well. Write programs to work together.
In Unix, there is even a standard interface for simple movements, the text stream, which enables almost trivial little programs to be combined to solve any problem. Horology's use of "complication" also reminds me of Rich Hickey's adoption of the word complect for talking about software systems. See, for example, his RailsConf 2012 talk, Simplicity Matters. Tools that interleave multiple strands of functionality are inherently less reliable, in addition to being harder to work with, so we should seek to create tools with a single strand. In order to talk about timekeeping devices that perform several functions, watchmakers specialize their term. Informally, a grand complication is a device that contains at least three complications, with at least one timing complication, one astronomical complication, and one striking complications. It might be instructive to classify in a similar fashion the ways in which programmers typically "complect" their code. The Wikipedia page for "complication" states explicitly that adding complications to a watch makes it more difficult to "design, create, assemble, and repair". That sounds a lot like how programmers feel about complexity. But the page also gives the sense that fine watchmakers revel in complications and see them as a sign of great achievement. Some watchmakers even glory in the complexity of their timepieces. It seems that watchmakers have more in common with programmers than you might think. Perhaps Heber is on to something here. -----