I’m having something of an interesting experience at the moment- a real life learning experience. I find myself sitting on the other side of the table. See, I’m hiring a lawyer.

Some explanation is in order here. All my adult/professional life, I’ve been a software developer- which means that people come to me with problems to solve (mainly by writing code). And the customer always has an idea of what they want- precise, impossible to articulate, and (as a general rule), wrong. Or, if they’re being honest, they have no idea what they really want, they’ll just know it when the don’t see it. And I’m stuck trying to translate the handwaving, blobs and lines drawn on a whiteboard, and “you knows… kinda like but not really”s into terms that make some sort of sense in terms of computers and software. Preferably with only reasonable amounts of work involved (’Hurt’ is not short for ‘Hercules’, and Kevin Sorbo I am not).

The law is like software, in that it’s arcane, complicated, and strange. And you really want a professional involved (even better, a competent professional), or the results will be expensive, painful, and drawn out. Actually, the law, done badly, can be even more expensive, painful, and drawn out than software.

As a side note here- this is why license agreements written by programmers are worth as much as code written by lawyers. If you not know the language, and more importantly operating environment (also known as the body of precedent), you’re in for a world of hurt. For many of the same reasons.

So anyways- now I’m finding myself on the other side of the table, handwaving a lot, with more than my fair share of ums and kindas and you knows. And counting myself lucky that the guy on the other end of the table not only knows the law- he also knows my business, software. Which allows me to use terms specific to the problem domain at hand, like “cross module inlining” and “functors”- and he understands what I’m talking about (or can be taught with a very small amount of highly techincal explanation).

Which brings me to the real point of this rant- in my opinion, it’s not enough to know programming. You need to know something else- you need to know your customers business, whomever your customers may be. Programming is like Celtic music- pretty boring by itself, but great when mixed with something else. In my CD, I have lots of celtic plus something music- celtic plus rock, celtic plus classical, celtic plus jazz, celtic plus african, celtic plus new age- but no pure celtic. My all time favorite celtic back (the now defunct, alas, Six Mile Bridge) was two electric guitars, drums, and a Hungarian mandolin. God save me from the Clancy Brothers or the Irish Rovers- despite my ethnic heritage, that stuff is just dull. Now, Eileen Ivers doing “Pachabel’s Frolics”, where she starts the song in classical Violin mode, and ends the song in the pure Irish Fiddle (the difference between classical violin and Irish fiddle is one of attitude, not instrument), now that’s interesting.

And valuable- as a programmer, you are there to solve problems. This has a lot of implications. Solving the problem(s) may, likely even will, involve writing code. And debugging code- code that doesn’t work right doesn’t solve the problem, and thus has no value (except to the extent that it might be fixed and thus solve the problem). I don’t care if you are the grand national champion alligator wrestler, you’re there to drain the swamp, and you need to keep that in mind all the time. And customers don’t generally care about meta-solutions, things that aren’t solutions but might be turned into solutions with some programming- how is this different from the customer’s point of view than where they started? Beware of over generalizations. And so on.

You’re there to solve problems, and the first step to solving a problem is know what the problem is. Which requires knowing you’re customer, the person you’re solving a problem for. So, the most important thing for a programmer to know is something other than programming. This is something most programmers forget, and that we don’t do enough to teach new people coming into the business. And that’s a question we should be asking ourselves constantly. What problems are we solving? Who are our customers? What are their needs, possibilities problems?

Something every college student studying CS should know is that all programmers are, by necessity, double majors. That’s what I’m learning again, being on the other side of the table.

So, what’s your major?

Popularity: 3% [?]

OTUG Meeting on Static vs. Dynamic Typing, November 15th, 2007

Hosted by Hamlet D’Arcy and featuring Charles Nutter (a major powerhouse behind JRuby). Also featuring Paul Cantrell (who doesn’t have a website that I can see), and possibly Hamline’s own Professor K: Professor Wolciech Komornicki.

Should be an excellent discussion.

Popularity: 5% [?]

Continuing the conversation had by Raganwald, me, and a lot of the rest of the blogosphere:

The Java Posse Responds to My #Equals Issue
(If you don’t know the Java Posse, check out their website/blog/podcast. It’s good stuff.)

The answer they gave was an interesting one, which I’m still sitting on and working in my head. Here is Martin OConnor’s response, for those too lazy to read the (very interesting) thread:

Your class hierarchy is flawed. ThreeDeePoint does not naturally extend TwoDeePoint, because a Three Dimiensional point is not a kind of Two Dimensional point. They represent two very distinct concepts. Essentially, when you extend TwoDeePoint with ThreeDeePoint, you are saying that ThreeDeePoint is a special kind of TwoDeePoint. I would submit, therefore that the problems you are observing are less due to the impelmentation of Object.equals(), and more as a result of your chosen class hierarchy design.
[...]
What I was trying to explain, (although poorly), or more precisely hinting at, is The Liskov Substitution Principle. This is an Object Oriented design principle that states that any reference to a base class should be replaceable with a reference to a derived class without affecting functionality. What my previous post had attempted to say is that since the TwoDeePoint and ThreeDeePoint classes do not adhere to The Liskov Substitution Principle, the design, in this particular case is flawed.

(For those that don’t remember my “TwoDeePoint” and “ThreeDeePoint” example, check my post, “A Java Gotcha”, where I first get into the #equals/#compareTo issue.)

So, is it invalid for a 3DPoint to inherit from a 2DPoint? The general way this is phrased is “is it legitimate to say 3DPoint is-a 2DPoint”? Well, that depends on what your definition of “is-a” is.

After all, the semantics behind a 3DPoint imply it is a 2DPoint, as it has all the same qualities of a 2DPoint: it simply adds the idea of a third dimension to the existing definition. Semantically, a three dimensional point is a two dimensional point residing on a particular point in the three-dimensional axis, and it has all the capabilities of a two dimensional point on that particular plane.

On the other hand, the Liskov Substitution Principle gives a much stricter definition of “is-a”. I’d like to look at a colloquial definition of the principle, and then a formal definition, because there is a huge gulf between these things.

Colloquially, it basically says that Foo should not inherit from Bar unless Foo is-a-specialization-of Bar: that is, Foo is a limitation upon Bar. So the inheritance in that example is invalid: 3DPoint is not taking 2DPoint and limiting it, but it’s taking 2DPoint and extending it.

Adopting this approach to inheritance will substantially limit its use, and is going to lead to some repetitive code — in my example, all the 2DPoint methods would have to be re-implemented as 3DPoint methods. But it does side-step the #equals/#compareTo problem, in that a specialization will have to rely on the same #equals/#compareTo definition as its parent class.

And that’s where the rub is. Using the cite by way of Wikipedia, let’s look at the formal definition of this principle:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

My rub is with the phrase “a property provable about”. Consider a type of a matrix (M) and a diagonally symmetrical matrix (S). Specifically, there exists M#setXY that sets the item at [X,Y] to a vaue. In S#setXY, we override it so that it also sets the item at [Y,X] to the same value as [X,Y] was set to (thereby maintaining symmetry). Now, S is a colloquial specialization of M, but it could be a violation of the substution principle, since it changes the postcondition of M#setXY: is the fact that the rest of the matrix remains unchanged in M#setXY constitute “a provable property”?

Assuming that “a provable property” is basically analogous to the precondition/postcondition properties, I suppose there is no reason that M#setXY has to specify that the rest of the matrix remains unchanged. What we would basically be arguing in this case is a very liberal interpretation of the role of preconditions/postconditions: the postconditions of M#setXY need not specify everything that M#setXY does, and the preconditions of M#setXY might not need be all true.

If this is the case, then calling a method becomes a very, very scary thing. It is now legitimate for me to implement M#setXY to set every item in the matrix to NaN, delete your hard drive, send out 3000 spam mails a second, and make some coffee. As long as M#setXY ends by setting [X,Y] to the given value, it is an acceptable implementation of inheritance.

So, if we deny this liberal interpretation, and then S is not a legitimate case for inheritance of M, because S#setXY does something which M#setXY doesn’t specify. So the specialization we’re talking about by way of the substitution princple is extremely limiting: basically, all you can do is throw a different sub-class of already-declared exceptions, return subclasses of already-declared return values, and add methods which do not intersect/interefere with the provable properties of any other method, including #equals/#compareTo.

This limits inheritance to very few cases. Certainly, the implementations of abstract class are allowed, assuming that the abstract class leaves enough breathing room (e.g. vague enough declared exceptions) for an underlying implementation. This can be seen, for instance, in Java’s AbstractCollection. Anything which tacks on a piece of non-identifying information or non-interfering functionality works just fine, too, although I’m having trouble coming up with a good example for either of those.

Some people older and wiser than me once asserted that no inheritance should be done on anything other than classes explicitly defined for inheritance (i.e. abstract classes). At the time, I thought that was extreme, and so I discounted the position. I’m increasingly starting to understand it, though, and I think I may be signing on.

Popularity: 10% [?]

David Hussman has published his DevJam.biz website, which was previously just “Coming Soon”. Looks good.

Anyone in the Agile development scene in MN who doesn’t know David should go out of their way to meet him. He’s sharp, and really understands both the nature of technical development and business needs. His insight into how to balance those needs, and how to leverage the technology when appropriate (including not using it when it is overkill) is really second to none.

Popularity: 3% [?]

Raganwald: Too much of a good thing: not all functions should be object methods

It’s a great post. I took on the general argument writ small when I fought with Java and its #equals method in these posts:

Description of the Problems Java has with CompareTo and Equals
A Problem with my solution to the Java CompareTo and Equals Problem
Analyzing an attempted solution to the Java CompareTo and Equals Problem with Commons-Lang

Popularity: 4% [?]