 |
privacy |
|||||||||||||||||||||||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2006-02-25Blinking at Quarks: Is It an Object that I See Before Me
{tags: object-oriented development OO concepts Deborah Armstrong What Computers Know conceptual integrity taxonomies orcmid} Professor von Clueless in the Blunder Dome: The Quarks of Object-Oriented Development. I was discussing Deborah Armstrong’s analysis of fundamental OO concepts in last week’s buddy call with colleague Bill Anderson. It was easy for us to start challenging the lack of sharpness in the definitions. I think it is worthwhile to point out a couple of difficulties and also point out how a common practice of software development trips us up. Descriptive Versus Prescriptive TaxonomiesBefore starting, I must emphasize that Armstrong’s classification is meant to be descriptive. Works of others containing descriptive (or prescriptive) characterizations of object-oriented development were analyzed and summary descriptions of the top eight concepts were then synthesized. On reflection, it might have been useful to use a lexicographic approach that tolerated different definitions that seemed to cluster out. That wasn’t done. To the extent that the result lacks sharpness and may even be confusing, that is evidence for the state of the shared understanding of experts on the matter. In offering alternatives, although they strike the author as the complete truth of the matter, please ignore the presumption of validity. These offerings should merely be taken as demonstrative of where clarity is lacking and incoherence can be found. Reality Versus Computational RepresentationIf we look at the tabulation for OO Abstraction, OO Class, and OO Object, it is possible to observe that the way the nomenclature is based on somewhat-familiar terms creates pitfalls when it comes to grasping what an application of those concepts is about and how that is manifest in computational artifacts and behaviors. In discussion with Bill I noticed that the OO-specialized categories for fundamental concepts are blurred by their suggested connection with (conceptualization of) reality as it figures in human experience. I didn’t catch that in replicating Armstrong’s taxonomy. I will redeem myself by capitalizing and prefixing (OO-) my mentions of OO-development concepts. I am following my own advice with regard to data modeling. (I won’t go so far as to speak of ooClass and ooObject, as amusing as that could be.) Confusion with Ordinary Abstraction, Class, and ObjectIt is easy to confirm that OO terms are confused with the ordinary use of abstraction, class, and object. That confusion aso clashes with the specialized usages in philosophy and (mathematical) logic, including set theory:
Extensional Versus Intentional UseIn computation, it is also important to differentiate between the extensional nature of something (the “what it is” in fundamental terms, if we are so bold) and the intentional view of something (the “what it is for” or what it is an instrument or medium of). The second is always tied to some situation or context and relies on external conditions not that inseparable from the intentional view of thing itself. (Even what we take as extensional is possibly intentional at a lower level, but we have to start somewhere. I touch on how we avoid falling down the rabbit hole in a more-recent article.) For our purposes, we don’t have to worry about the philosophical subtleties here. (The injunction to concentrate on the extensional is attributed to the philosopher Willard Van Orman Quine). The cases that stand out in the OO-development taxonomy are much more bare-faced. Reality Versus ProblemsIn the definition of OO Abstraction, we see that it is a purposive activity for “creating classes to simplify aspects of reality using distinctions inherent to the problem.” The more I look at this, the less I understand what it could mean. I am baffled about the prospect for simplifying aspects of reality. I am even more concerned that “inherent to the problem” clearly depends on a particular perspective and is certainly highly-contextual. (I also notice that OO Abstraction is characterized by its purpose and not its nature, whatever its nature might be.) I have the following questions:
The Subject Versus the RepresentationMy final example concerns OO Object. In the definition distilled by Deb Armstrong, it is “an individual, identifiable item … which contains data about itself and the description of its manipulations of the data.” I must confess that “item” leaves me cold, and I wonder what had the commonplace “entity” be avoided. My greater concern has to do with this business about data.
Pondering this, I think what’s missing is how OO Objects are organized to preserve some represented invariant in the way that data and procedures (the behaviors the OO Object is said to offer) are constrained and coordinated together. Furthermore, these constraints, enacted in a computational entity, are what preserves some essential correspondence to something tied to our purposes for the OO Object. It’s too mischievous to call this entity-of-our-purposes or intension “the object.” Let’s speak of it as the OO Subject when we need to be so precise. (I fear this opens up a torrent of refinements and my use of “subject” is already on shaky ground.) 2006-02-19The Quarks of Object-Oriented DevelopmentDeborah J. Armstrong provides a valuable conceptual classification of features for object-oriented (OO) development (2006). Armstrong reviewed the literature for characterizations of essential OO qualities. She synthesized a taxonomy based on concepts emphasized in a majority of 88 sources. I recommend the general adoption of the eight fundamental concepts (quarks) and the distinction of structure and behavior that Armstrong recommends. {tags: object-oriented development OO concepts Deborah Armstrong What Computers Know conceptual integrity taxonomies orcmid} The Recommended OO TaxonomyArmstrong is looking for more than identification of fundamental concepts for which there is good agreement. The proposed taxonomy is organized to show how “these concepts fit together in a coherent scheme.” Armstrong recognizes two categories (called constructs): structure and behavior. The structural concepts are focused on the class/object relationship in OO approaches. Behavioral concepts relate to object actions within an OO system. In repeating the article’s Table 3, I have added the italicized summaries that are provided as part of the analysis in the text. If there is anything different in the 2003 version originally submitted for publication, I have added those definitions too. Definitions that are identical between the text, the table, or the two versions of the paper are not repeated.
Reflections on TaxonomyI notice three lessons here:
Reflections on Object-Oriented TechnologyI’m also intrigued by the first level of concepts that did not rise above 50% popularity among the materials that were analyzed. I think we should pay special attention to the critically-important manifestation category, including execution architecture, deployment, and instantiation concepts. I’d like to see that singled out for additional treatment. I also think this would help us shake out the already-proposed categories. For example, the notion that it is the classes that respond to messages (see the Polymorphism entry) smacks of a serious implementation assumption. There are other ways that providing a category for key implementation features would help us expunge residual implementation notions from the top eight fundamental concepts. The influence of the particular OO technology on how OO development is approached cannot be
[update 2006-02-19-15:42 Well, I got an idiom wrong (see the last paragraph) and took the opportunity to tie in “What Computers Know.”] Performing in Teams: Where's the Praxis?FREAKONOMICS BLOG » A Creative NASCAR Incentive. Stephen J. Dubner’s observations about NASCAR teams has me wonder about how software-development groups excel as teams. In particular, can high-performance teams function with group rather than individual incentive/compensation? In the case of the Hendrick Motorsports team bonus for making the Chase for the Nextel Cup, Dubner speculates
{tags: Freakonomics Roland Fryer teamwork software engineering praxis group incentives orcmid} My speculation is that there really must be identification with the group and ownership of the group result for teamwork to happen, whatever explanation the performers offer for the extra effort. I have seen software “teams” respond with individual cynicism and a fantastic array of undermining passive-aggressive behaviors. Having practiced most of those in my career I can provide an account of what happens in terms of what I would be doing in those circumstances. Whatever’s happening, it isn’t pretty and its always “their” fault. This didn’t come home to me until 2003 when I was in an M.Sc in IT software engineering course where we were called upon to form and work as teams. This led me to understand that, even in a course where process and teamwork is the point, cowboy behavior tends to be dominant. The pattern seems to be justified by the view that everyone else is a stupid slacker and by goddess, I am going to get a top grade no matter what. It was clear in that eight-week experience that we had not constituted ourselves as a team and that it was extremely difficult to do so in a distant-learning team of four spanning 16 time zones. So I suppose it was remarkable that we produced any result at all. It also seemed to me that the academic organization had no idea how to deliver a course that relied upon team conduct and team results. It may be that the forming teams of people who are at best casually related is doomed, but I also think that introducing this into the classroom is likely to be a case of the deaf misleading the blind. Indeed, for the other courses in which there were group/team projects, the requirement for teamwork was actually far less than in the software engineering course. Oddly, my greatest experience of teamwork was in a database course where we agreed on our data model in a Netmeeting session spanning eight time zones. A single episode of shared whiteboard and audio connection provided, for me, more experience of a team than anything else in the entire program. I have checked around a little bit with others who have performed in or delivered an academic software-engineering program, and the failure of teams and justification of cowboy behavior seems widespread. When I am most despairing over this, I tend to proclaim that software engineering is too important to be taught by computer scientists. For those of us raised in a self-styled high-individualism society, I say it takes recurring acts of personal courage to own a team result as our own and also continue to practice achieving powerful results under those conditions. Oddly, although portrayals of team sports all feature something about fashioning of genuine teamwork, it tends to be a celebration of the coach and the coach’s struggle when not a depiction of the brilliance of a single player. (The film Tin Cup provides a notable exception and I wonder how many detect that. The underlying theme of We Were Soldiers is also something to pay attention to, despite its cinematic focus on the commander and on notions of leadership.) For all of these reasons, I want to know more about this experiment in group incentive that Dubner cites:
|
|||||||||||||||||||||||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |