Upcoming Database Agility Online Training

I will be running another course on database agility over the internet starting on March 16th.  This course is designed to give you an understanding of what the impediments to Agility in database development are and, of course, to show you how to overcome those impediments.

For more information click on the following link:
http://www.netobjectives.com/course-schedule/database-agility-online-mar-2010

Facts and Certitude (A Retardation Celebration!)

Remember this dumb article?

Well, I've heard back from the team involved - at least from the assistant.

I'll paraphrase:

Them: You don't understand, this guy didn't agree with us.
Me: Oh I get that, how come that's wrong and you not agreeing with him is okay?
Them: His argument was "Nuh-uh."
Me: Are you sure that wasn't your argument?
Them: But he didn't accept a fact.
Me: Where does the fact come from?  How come your source is more valid than his?
Them: No... no... you just don't get it.  This is a proven fact.
Me: Proofs are only ironclad in how it leads from assumptions to conclusions.  The postulates (and, therefore the conclusions) themselves are still open for debate.
Them: You're trying to claim I don't understand.  Thanks for your input.
Me: (thinking duh!) I hope you see how funny that is.  I sure do, so thanks for enriching my day.

I'll go out on a limb here and say that there are some far worse arguments against the freedom of the press than these people - Glen Beck, for example - but, still, the fact that they are contributing to the media and inundating the weak minded with false certainty makes them part of the problem not part of the solution.

We need to come up with a system that routes people like this to jobs for which they are better suited.  For instance, I would suggest that the person I talked to should be taking out the trash rather than filling people's heads with it.

Original Sin

Either make the abstraction good and its variations good, or make the abstraction bad and its variations bad; for the abstraction is known by its variations.

 We do not inherit to specialize, we inherit to add variation behind abstraction.  Yet both of the major platforms today - Java and .NET - force every object to specialize a base class.  For Java, you have to inherit java.Object, and for .NET it is System.Object.


...but it really doesn't matter; the damage is done either way.

This is the "original sin" of software development.  Every object must be able to determine if it is equivalent to another.  Every object must be able to bucket itself with equivalent and similar objects.  Every object must be able to convert itself to a string.

Whether you need these features or not, you must, at the very least, inherit them.  The true nature of abstraction is, therefore, tarnished.  You can never have a pure interface for every object is tarnished by the sins of its base class's designers.  Consequently, programmers will, forever, be weighed down by the mental model of objects as "data with behavior" that is so apparent in their platform's design.

I hope that, when he next real platform (ruby and python don't count, guys... I hope you all figure that out, soon), its architects will be more enlightened.  In the mean time, I hope you can bring yourself to flat-out ignore those garbage behaviors that every object inherits.

P.S.: Isn't it interesting that we, the gods of software, are the ones truly responsible for a sin of design committed by a single ancestor and that said sin burdens its every inheritor?

Remember when Facts Ended Arguments?

I sure don't.

Thanks to fark, I recently stumbled upon this article.  Go ahead and read it for yourself, if you like.  If you'd prefer to spend a few minutes of your life doing something more productive - like setting an orphanage on fire or smoking crack - I'll save you the trouble with by summarizing:

"I miss the days when people who didn't agree to me would simply cow tow to an appeal to authority."

Yep.  Those were the days.  I sure miss the days when people refused to think for themselves or ask "why."  Remember all the good things that came out of mindless obedience to those who claim knowledge with sufficient emphasis?  It's hard to count them all but I'll take a shot:

• Witch-hunts
• The Inquisition
• The Crusades
• The "War" on Terror
• The "War" on Drugs
• The Holocaust

I knew I would never make it through to the end of the list... after all, I'll probably only live another thirty to sixty years... but it was worth a try.  That guy's article is like a handmade Christmas card: heartfelt an the product of careful attention but ultimately worthless.

If you don't agree, indulge me by considering the following questions:

• Do you understand the difference between "hypothesis," "truth," and "theory?"
• What do you think the difference between our collective model of the universe and the universe itself is?
• Do you remember when facts settled arguments?
• When, specifically, was that?
• What are “facts?”
• What makes a “fact” good enough to “settle” an argument?
• Who chooses these which assertions are “facts” and which are “opinions?”
• Was phlogiston theory a fact when it was ?
• Is it now?
• Was it one before it was believed?
• If it wasn't a fact, was it bad?
• Do you have the power to tell me which facts are true and which will be contraindicated in the future?
• If so, can you tell when?
• (I would pay you handsomely for the use of that talent, by the way)
• How, in your mind, do facts and beliefs differ?
• What is the difference between proof and evidence?

Is Encapsulation Creating Duplication?

The answer is a definite "no."  Each is the other's anathema.  Yet sometimes it looks like concision and encapsulation are at odds.

Let's take the simple example of encapsulating construction.  When you encapsulate a constructor, you might do something very simple as follows:

public class MyService {
  private MyService() { }


  public static MyService GetInstance() {
    return new MyService();
  }
}

The argument for encapsulating construction are pretty ironclad.  It's essentially free, and it lets you promote a class from a concrete class to an abstract one.  At least, theoretically speaking...

When you get into it, you find that something very annoying occurs.  Let's say that we need a new parameter when producing instances of MyService.  We have to make that change in two places.

public class MyService {

  private MyService(string parameter1) { }

  public static MyService GetInstance(string parameter1) {

    return new MyService(parameter1);

  }

}

This is arguably unavoidable: the system was closed to variation in whatever parameter1 represents.  We had to refactor the system to be open to that kind of variation and closed to future change pertaining to the same concept.  Yes we had to make a change in two places to be complete but we did it to improve design so its okay.

What about when we add another parameter?  Is that just another refactor?  What about when we want to delegate some of the work off to another method?  Do we now have to maintain two parameters in three signatures and some number of method calls?  In areas where change is the most common, the problem becomes clear quickly.

"Keep it simple!" someone might cry, "That's what you did wrong, you made things complex by adding a whole bunch of unnecessary methods."

Nonsense.

The problem isn't that I improved design.  The problem is that I missed an opportunity to improve design again when I added the parameter.  I made the called methods open-closed to the arguments with which they could be called (which is the whole point of a parameter) but I didn't encapsulate them from changes to the arguments, themselves.

What if I had done something like the following, instead?

public class MyService {
  public class InstantiationArguments {
    public string Parameter1 { get; set; }
  }

  private MyService(InstantiationArguments arguments) { }

  public static MyService GetInstance(InstantiationArguments arguments) {

    return new MyService(parameter1);

  }

}

That would have been a much better refactor.  For one thing, I would have been applying the open-closed principle correctly - rendering the thing I am refactoring open-closed to the kind of change I am introducing (changes to method signature).  For another, I could have done my work in smaller steps: first making the instantiation behavior open-closed to its parameters, then adding the parameter and handling its value.

The point here is this: the principles of design seem unassailable; at least, with our current knowledge.  When it look like a principle isn't working, it is most likely that you (or I) just cannot see how it applies and less likely that the principle is wrong or requires refinement.

There is no room for "moderation" when adhering to principles.  If there were, they wouldn't be principles.  You either refine them, figure out how to follow them, or perish at the hands of someone more competitive.

Goad Testing

Well.  I've spent long enough with this particular writing sitting on the shelf collecting dust.  I decided to finally get off my ass and publish it.  It is entitled Goad Testing: Deepening our Understanding of Automated Tests.  In addition to (hopefully) doing as the subtitle promises, the booklet teaches a technique that expands test driven development by ensuring that each test makes a distinction.

As was the case with Transition Testing: Cornerstone of Database Agility, I intend to have this writing be a short introduction to a broader concept.  Later, when I have more time on my hands, a book will follow about the larger concept.

Click here to check out Goad Testing now.