Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg

Author:Scott Rosenberg [Rosenberg, Scott]
Language: eng
Format: epub, pdf
Tags: General, Computers, Business & Economics, Industries, Social Aspects, Programming, Development, Software Development & Engineering, Computer Industry, Computer Software - Development, Computer Software
ISBN: 1400082471
Publisher: Crown
Published: 2007-01-16T00:00:00+00:00

Stamping aimed to introduce a kind of productive ambiguity to the computer desktop that more closely mirrored the way people think. It was not a simple concept even for the designers who had invented it; for the developers who had to make it work, it was even trickier. Computer programs used silos and trees and similar unambiguous structures because they helped keep data organized and limited confusion. If an item belonged to one group, it did not belong to another; if it lived on one branch of a tree, it did not live on another.

Human language is more forgiving: One word can mean more than one thing. This flexibility provides a deep well of nuance and beauty; it is a foundation of poetry. But it leads only to trouble when you are trying to build software. As OSAF’s developers struggled to transform the innovations in Chandler, such as stamping, from sketch to functioning code, they repeatedly found themselves tripped up by ambiguity. Over and over they would end up using the same words to describe different things.

Take item. To the designers an item in Chandler was anything a user thought of as a basic piece of data. A single email. An event on a calendar. A task or a note. But the back-end world of the Chandler repository also had items, and its items were subtly but substantially different from the front end’s items. A repository item was a single piece of information stored in Chandler’s database, and in fact you needed many of these repository items to present a user of Chandler with a single user item like an email: Each attribute of the user item—the subject line, the date sent, the sender’s address, and so on—was a separate repository item. At different times in Chandler’s evolution, proposals arose to resolve this problem—to “disambiguate” the word item. Maybe the term user item could always be capitalized. (This helped in written material, when people remembered to do it, but not in conversation.) Maybe another term for one or the other type of item could be adopted. (But some of those proposed, like thing, were even more ambiguous, and none of the proposals stuck.)

The Chandler universe was rife with this sort of word overlap. The design team kept using the term data model to refer to the list of definitions of data types that the user would encounter along with all the attributes associated with that data type. For example, the data model would specify that every note had a “date created,” an “author,” and a “body text.” But to the developers, data model referred to a different, more technical set of definitions that they used to store and retrieve data at the level of their code. What the design team called the data model was really, in the developers’ vocabulary, the content model.

Then there was the problem with the term scheduled task. In the design world a scheduled task meant an item on a user’s to-do list that had a date and time assigned to it.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.