[clug] On Analogy, was: Re: [OT] Bjarne Stroustrop on [SEC=PERSONAL]

[Alex Satrapa]

On 09/04/2010, at 11:40 , Steve McInerney wrote:

> When analogy is used as THE basis of "why I am right and you are wrong"
> in an argument; walk away.
> 
> Or: The argument will devolve off the original topic and onto whether
> the analogy is correct. helloooo bus shelter. Also a walk away
> situation, as again, folks are arguing solely for an argument/therapy
> session.

Arguing about whether the analogy is correct can shed light on assumptions that one or the other party have made about the subject of the analogy (eg: plumbers not being clever enough to solve problems). Therapy session indeed - people go to therapy for help in sorting out deep emotional issues. How is arguing the assumptions embedded in an analogy not going to help the argument the analogy was supposed to support?

When one says that programming is like plumbing, is one inferring a direct correlation between function of the role in the larger hierarchy of the industry, or implying a social strata from which individuals in the trade are drawn in the larger hierarchy of the society? Is there some other way in which programmers are like plumbers, apart from commonality in the human condition? Are programmers and plumbers more alike than they are different?

To argue, for example, that "plumbers simply slot predefined solutions together" is to seriously underestimate the plumbing profession as a whole, while simultaneously overrating J2EE/Django/Rails/API programmers in general. Programmers using frameworks such as J2EE, Rails, the iPhone API or Django also "simply slot predefined solutions together". Some engineer, architect or designer has already told them what to do. Plumbers in the meantime have to diagnose 

And then there's the issue of etymology. Some people consider themselves to be simply "programmers" when they are in fact software engineers, interface designers, quality assurance and user testing all rolled into one. I'm arguing for definition of "programmer" as "person who cuts code". In common parlance, "code monkey". Other levels in the hierarchy of this engineering discipline would be Engineers responsible for project planning, progress monitoring, quality testing, and all the management side of the software project, along with Designers responsible for software architecture, user experience, corporate image compliance, etc.

Outside the hierarchy are computer scientists who come up with cool stuff like a new memory management scheme that allows all existing software to run 20% faster, develop RISC architecture, invent a new database paradigm, build a robot capable of sorting and folding towels, etc. Grouped with the computer scientists are the tinkerers and inventors - folks who aren't particularly relevant in the day to day operation of industry, but who will once in a lifetime come up with something that redefines the industry.

"Hey, industry - remember how last year we were writing declarative programs for Von Neumann architectures? The new model is parallel computing using Fitzburgen logic and quantum functions. Oh, you don't know quantum physics? Guess it's going to blow your mind that 'hello world' is the hardest program to implement in this model!"

(which is the gist of the rest of the essay that I over-trimmed, missing the morlocks and eloi story, an inappropriate use of Dunbar's number, the shearer vs sheep farmer story, and the "if plumbing was done like software has been written" analogy)

Alex