Software Etymology

Introduction

There are a number of "What Is ..." pages on this Wiki, each concerned with the definition of a term that corresponds to some principle of software development. These terms are sometimes problematic because of the rate of semantic change that resulted from their application in an area in which rapid change is not only the norm but also the key to survival. But things can change too fast sometimes, leading to fragmentation of concepts and poor communication. the "What Is ..." movement here is a healthy thing, both literally and figuratively. It's good for us to know what each other means, and that can result only from a certain degree of literal health or wholeness among terminology and its application.

As older, borrowed meanings and their terms drift to new stations in our lingo, it requires effort to stay coordinated. But even with effort, sometimes a term reaches multiple semantic attractors so that practitioners are unwilling to ditch their preferred interpretations in favor of someone else's, even if the reward is better communication. When negotiations about current meaning come to a halt, one reflex is to reflect. "How did we get here?" In other words, scan the history of semantic evolution, and then see if we can identify a preferred path from past to present, perhaps selecting certain branches over others based on more of an architectural view of the process.

That's where this page figures in. Sometimes, if you investigate older (even ancient) meanings of the terms you use today, and if you hold some of those meanings in your mind simultaneously with the meanings of modern application, you get a pleasant kind of synergy where past and present fuse into something transcendent - deeper insights into the way humans think and build and carry on. This can result in reduction and simpler understandings, the value of which should be obvious for our field.

The WhatIsAnalysis page really touched me (before I touched it, that is). For one thing, it reminded me of the day I asked John Palmer, during a survey of object orientation approaches, whether "analysis" in the popular lifecycle models means the state in which requirements are wrought. The answer was not yes, but it was also not no, and it left my internal model broken for a while. But it also made me realize the sloppiness with which we use such terms and the fuzzball of communication that results from that. More importantly, it suggested that these terms are not defined for us with any authority.

On WhatIsAnalysis, I tried following the lead of Bob Haugen in suggesting that the etymology of the word could provide valuable and practical information, but was countered with the advice that when people ask that question, they are asking for a survey (perhaps even an average) of current interpretations. In other words, a description of normative modern application, not a prescription for more correct or more effective interpretation. So be it. The present page begins where WhatIsAnalysis and similar pages leave off. It's for those who are interested in history and a degree of depth. Borrowing from WhatIsAnalysis, it's very much about analysis, especially in the sense of "getting to roots". It's for people who like roots.

-- WaldenMathews

Etymologies of Software Terms

Analyze: Literally, to break apart. Chemical analysis identifies elements from compounds. Fourier analysis identifies simple frequencies from complex harmonic compositions. In software, we talk about decomposition (as in "FunctionalDecomposition"), and separation (as in "SeparationOfConcerns" in problem domain analysis). It may be a mistake to think of analysis as being any discrete or distinct phase of a development, just as it would be a mistake to think of breathing as a phase of life. Also, there is nothing historic in the word analysis that suggests a particular level of abstraction, as in high level design.
Architect: Literally, "first builder" (from Greek arche-tekton). Arche (first) could mean first in sequence, first in importance, or any other number of "firsts". Note that linguistically, 'architect' is the basis for 'architecture', not the other way around. The "first" part certainly implies authority, perhaps seniority. But the term overall is not very descriptive. For instance, it does not discriminate between modern roles of designer and project manager. Also nothing directly related to ConceptualIntegrity.
Assure (new!): As in "quality assurance". The original meaning of sure was safe, and the original meaning of safe was whole, as in healthy. Assuring, in a deep sense, means promising the quality of wholeness. As this applies to (process) quality assurance, it means that whatever body of standards is being used to guide development, that body is being applied as a whole and consistently, as opposed to piecemeal.
Control (new!): This word is so deeply ingrained in our thinking that it's hard to define or even describe it without self-reference. Contra roll means there is a second writing against which the first writing can be compared. Usually we think control means changing things to be the way we want them, but the etymology is void of explicit change semantics. Instead, it brings focus on that second clause: the way we want them, which presumably is what's captured in that second writing. Control equals comparison.
Culture: Something that has grown in response to someone's caring labor, as something cultivated, according to Latin roots. By this definition, many software organizations may not be cultures at all.
Design: Literally, to "mark out", this is an interesting one. Strictly speaking, when you "design in your head", you're not designing at all. You have to commit it to paper, then you're designing. In this respect, design is closer in meaning to our familiar usage of the word plan, and the dictionary considers them synonyms. You may do some analysis in your head, then write down the results in a design. (But analyses are not the only activities that result in things that can be marked out.)

More on the Etymology of "Design": While "to mark" is part of the meaning of design, another important etymology meaning is "to follow", as in to follow the "sign" or "mark" or standard of your leader. This meaning also resonates very well with "plan", which is the standard builders follow.

Manage: Literally, to lay your hands on something. This word came to us via the French language, where it took on the popular meaning of handling horses. For you programmers out there, this kind of brings new meaning to the word 'bit', eh?
Model: From the Italian modello, literally a small measure of something. BigModelsAreUseless because they defeat the goal: smallness. A model is only effective if its smallness lends greater tractability than the thing it models. A corner off a loaf of bread, containing both crust and crumb, is a model of the loaf, and an effective one at that (when I'm hungry).
Problem: Literally, something that is thrown forward. When you throw something forward to be tripped over, you've created a problem. "Obstacle" is considered a synonym. I've put this here for completeness (see "solution" below).
Solution: From the verb, to solve, which means the same thing as dissolve, that is, to break apart into tiny enough pieces so as to remove. This is a technique for destroying problems, and note the similarity to analyze.

The purpose of this page is to give us a historical perspective on the terms used to describe what we do. Other pages here are dedicated to common and current usage of these terms. I'd appreciate your respect in keeping the theme pure here.

Will undoubtedly add more in due time. Suggestions welcome, gentle comments, and what-have-you.

-- WaldenMathews

The terms Architect and Design are both defined, with neither making reference to the other. I've always wondered, what is the distinction people make between these terms? To me, they carry the same meaning.

Sometimes they're used interchangeably; other times, there's a distinction, in which case it's a question of scope. An architect has complete responsibility for a system or large subsystem, including ensuring that relevant requirements have been adequately gathered and met, while a designer might not be responsible for missing or wrong requirements, only for creating a design that meets certain requirements.

It's somewhat like the question, 'what's the difference between a first level manager, a third level manager, a director, etc?' In a tiny company or department, there might be no difference at all, while in a Fortune 100 company, there might be a rather large difference in the scope of responsibility at each level.

To put it another way, if someone's title is "architect", that typically implies "the buck stops here", whereas that may or may not be true of the title "designer".

Comments, Suggestions, Discussion

CategoryWikiFavorites