4 ms·

I question the notion that, just because the terms we use match up with another discipline (and this is likely not the only one), we are necessarily drawing a d

I question the notion that, just because the terms we use match up with another discipline (and this is likely not the only one), we are necessarily drawing a direct comparison with that other discipline by using those terms. Programming/development/whatever is full of ridiculous terms. We co-opt them from anywhere we want, we make them up, we apply them in multiple outlandish ways. We don't really need a reason, because "we" in this case means "people who decide what to call things," and it's not as though we have a Bureau of Naming for the Computational Applied Sciences running around forcing us to use good metaphors. I can see it being fun to throw around theories about how we came to use the various terms that occur in our field, but I definitely don't see them as being strict (or even, in most cases, loose) direct references to the same terms' usage in other fields. Sometimes a term works for someone; sometimes the generic terms that work for different people line up in ways that make sense in more than one context. This just reads too much into that.

seanlinehan 13y ago
I surely agree with you in the general, but I enjoy the line of the thinking that the OP is going down. The way I see it is that the language we use dictates how we think about problem solving. Even if we don't port the strict definition of a term one-to-one, we are still anchoring our approach to the mind-space that the other term occupies. I read this post is as saying that we are no longer using the appropriate metaphors -- we are anchoring on counter-productive terms. These metaphors clearly were relevant at some point, but the field in which product developers play in has changed dramatically. If the game has changed, then it would seem that anchoring our language on new metaphors would make sense. If we use strong metaphors that more closely resemble the work we are doing, it could help us accelerate our problem solving. As with all ideas, we will see if others agree with the OP. Personally, I think the newly proposed metaphor of composition is more descriptive than that of building.

seanlinehan 13y ago

I surely agree with you in the general, but I enjoy the line of the thinking that the OP is going down. The way I see it is that the language we use dictates how we think about problem solving. Even if we don't port the strict definition of a term one-to-one, we are still anchoring our approach to the mind-space that the other term occupies. I read this post is as saying that we are no longer using the appropriate metaphors -- we are anchoring on counter-productive terms. These metaphors clearly were relevant at some point, but the field in which product developers play in has changed dramatically. If the game has changed, then it would seem that anchoring our language on new metaphors would make sense. If we use strong metaphors that more closely resemble the work we are doing, it could help us accelerate our problem solving. As with all ideas, we will see if others agree with the OP. Personally, I think the newly proposed metaphor of composition is more descriptive than that of building.