What is a class?

When I interview a candidate for a software developer position I often start simple; a question like "what is a class?" Often I get a perfunctory and incomplete answer like "functions and variables" and "a way to make objects" (sometimes they are much worse... way off the mark.) A few days later I will hear that the candidate wasn't happy that I asked such an "academic" question.

I don't want an academic answer. I want what I so rarely get... passion, interest, the beginner's mind, the journeyman's skill, a desire to explain, a mention of encapsulation or inheritance. I'm looking for an intelligent answer.

To myself I would answer something like this... "what underlies a class in object-oriented programming is the need to manage complexity through the classification of objects, both concrete and abstract. The class serves as a template for instantiating objects with distinguishing characteristics, represented as attributes and methods. The object's state is controlled by the object's attributes defined in the class. The object's behaviors are invoked through the methods defined in the class. In this way the class encapsulates data and functions together in a coherent way that can represent specific entities, elements of structure, events to remember, roles, etc. Classes provide structure and organization to the program with general-specific and whole-part relationships. A classes is the DNA, if you will, of the microorganisms that inhabit the larger software ecosystem."

By way of example, "I look at the objects around me and see how every Honda Civic is an instance of the same class with attributes like color, model, mileage and VIN number distinguishing each instance. When I want to pop the hood of another Civic the method is routine and familiar. My car is an instance of the specific Civic class. In turn, the Civic is a specific Car which is a specific of the generalization Vehicle. The Vehicle class has the attributes and methods that allow for things like vehicle license and registration and resale. The whole car is composed of parts, which are themselves instances of a classes. My insurance policy, a speeding ticket, a gasoline receipt are all class instances in some other structure of things-to-be-remembered. Every object instance has attributes and behaviors that are intrinsic to that class that allow for classification and structure."

This is the kind of answer I'm really looking for.

We are the Pakleds; You *are* smart!

As one of the weary consultants on a multi-year software development project for a major lending institution I observed what became known as the “Pakled-Customer Syndrome”. The Pakleds are a race of dimwitted aliens from Star Trek: The Next Generation, which are first seen in the “Samaritan Snare” episode (summary here). They co-opt the technology of other spaceships through manipulation, brainless praise and hostage taking. Responding in good faith to the Pakled distress call the Enterprise is ensnared by the Pakled’s intractable problems and pig-headed attitude.

In the TNG episode, the Pakled are characterized by the repeating of a few simple phrases. When the crew attempts to engage them in a dialog about their distress (e.g. Is your ship damaged?) the response is always; “Uh-hunh.” Diagnostic inquiry and problem-solving are met with; “It is broken…. Can you make our ship go?”, “Make our ship go”, “Will our ship go now?” Any perceived progress is met with oddly enthusiastic and sycophantic praise; “He is smart”, “You are brilliant”; but this turns out to be unproductive support and belies their hidden agendas.

On many projects the customer can be entrenched in their own Pakled-mindset and the project is soon mired in the resulting quicksand. As organizational behavioral dysfunctions, here is what characterizes the “Pakled-Customer Syndrome”:

• Snare one: The customer takes no responsibility for understanding the problems they face: “it is broken”. Ultimately, project scope cannot be managed when there is no meeting of the minds on what are the larger tasks at hand.
• Snare two: The customer cannot participate in their own treatment. Due to many surreal disconnects too many project resources are spent teaching the customer their own business; too few project objectives are being accomplished.
• Snare three: The customer provides fake praise and misleading recognition. The project believes it is accomplishing worthy goals and that customer value is being created; it is not.
• Snare four: The customer manipulates and ties up valuable resources. The more the project starts to unravel the more the Pakled-customer latches on to your team, drawing them deeper into their dysfunction.

At the heart of the "Pakled-Customer Syndrome" are the classic differences in expectations, especially around roles and responsiblities, that lead to conflict. In addition, there are implicit and hidden agendas which must be explicated before meaningful project progress can be made.

Energy Crisis: Solved!

We may be able to achieve thermonuclear fusion within the high temperatures of the collapsing bubbles produced during sonoluminescence. The official name for the reaction is Acoustic Inertial Confinement Fusion (AICF), which is well described in the "Bubble Fusion" Wikipedia entry (here). I first heard about sonoluminescence as part of course that I took some twenty years ago called "Underwater Noise". It covered cavitation and touched upon the experimental observation that the temperatures inside the cavitation bubbles was "as hot as the center of the Sun." As the years passed and cold fusion was "announced" the thought percolated into my brain: if a hydrogen bubble underwent this extreme temperature and pressure wouldn't there be a mini-fusion reaction. In the Wikipedia article they state: "In the March 8, 2002 issue of the peer-reviewed journal Science, Rusi P. Taleyarkhan and colleagues at the Oak Ridge National Laboratory (ORNL) reported that acoustic cavitation experiments conducted with deuterated acetone (C3D6O) showed measurements of tritium and neutron output that were consistent with the occurrence of fusion." Further, in 2005, students of Taleyarkhan at Purdue University published evidence confirming the previous result. Today we learn that a Purdue University committee has concluded that some allegations of research misconduct by Taleyarkhan were founded. (AP article). What a shame. So, where do we stand? I, for one, believe that since sonoluminescence does achieve the temperatures and pressures found at the center of the Sun it is a plausible avenue for scientific research. We must never let one individual or group's errors stand in the way of valid scientific pursuit.