Max Guernsey, III

Liberate Wall Street

2011-11-13T22:43:00.001-08:00

Are you tired of the Occupy movement? I am. It looks to me like a bunch of dirty hippies whining about the fact that they bought houses they can't afford and created an economic meltdown. How the hell is that Wall Street's fault?

Occupiers: You jackasses committed fraud and got away with it. Or, at the very least, your mortgage brokers did. Sure. There was a little bit of economic fallout from your decisions and the Wall Street people definitely didn't do anything to arrest the downturn you created. That hardly entitles you guys to bitch about them. It's not their job to look out for you.

Here's what I think we should do. We have a long history of liberating pansies who can't seem to take it upon themselves to fight back when occupied; most notably the French. Why don't we get together as Americans and start liberating Occupied spaces? We can start where it all began: Wall Street.

Liberate Wall Street!

The Gift that Keeps on Giving

2011-11-13T08:45:00.001-08:00

Christmas is approaching as rapidly as ever. In fact, it's approaching at exactly the same pace it always have and probably always will. I don't know what everyone wants but I do know what most people desperately need. They need the thing that helps them get through life, cold and twisted a thing as it is.

Unfortunately, if you're in the ninety-nine percent who don't seem to have this, nobody can give it to you. That is, nobody can give it to you but you.

This year, give yourself the gift that keeps on giving: a fucking sense of humor.

The Reason for the Season

2011-11-12T16:52:00.001-08:00

Hey everybody! Thanksgiving is coming up and I'm very excited. Of course, there's the feast but it's also a special day on which we all get together and celebrate the circumstances that afford us this free and comfortable lifestyle to which we have all grown so accustomed.

So this year, invite everyone you love to come over to your place. Gather around the table. Join hands. Pray, if you're the religious sorts. However you do it give thanks for the thing that allowed us to be us. Was it Columbus? No. Was it the corn and beans thing? I think not.

I wouldn't waste any precious thanks on those things. Instead, let's remember how it really happened and let that remind us of who we really are. We're the people who figured out how to make blankets into a weapon of mass destruction because winning a war with bullets, cannons, superior infrastructure, and trick beads wasn't going fast enough.

This Thanksgiving, instead of saying "Happy Thanksgiving," why not something that rings a little more true:

"They never knew what hit them."

"5 Whys" on the Economic Meltdown

2011-11-07T21:18:00.001-08:00

The economy crashed.
Why? Because banks were profiteering off of loans the borrowers couldn't afford.
Why? Because people were borrowing more than they could afford.
Why? Because prices were sky-rocketing.
Why? Because government created artificially low interest rates.
Why? Because the economy crashed.

Occupy the Slippery Slope

2011-10-16T09:53:00.000-07:00

"You know what? Maybe it's not just the top 1% who's the problem. That second percent is pretty rich and therefore responsible for my lot in life, too." It's not unlikely that the #Occupy movement will take that turn and this is what it looks like...

1% becomes 2%.
2% becomes 4%.
4% becomes 10%.
10% becomes 25%.
25% becomes 49%.

Nearly half of all Americans would be screwed by them trying to "make things fair."

Then, if they get what they want (read their literature), we'll have full scale communism which screws almost everyone all the time.

So here is my modest call to action. Go to the places where they are organizing and counter organize. Help them see that they are their own problem and nobody else is responsible for the choices they make but them. Be relentless with your reason and maybe we can avert the storm they are gathering.

I think it's time to invade China

2011-08-10T11:46:00.000-07:00

Check this out:

http://blogs.hbr.org/cs/2011/08/apple_stores_in_china_the_one.html

I know how we could enforce trademarks over there. We could threaten to default on our loans to them. We could place an embargo on them. We could start a good ol'fashion war with them. It's about time a World War didn't start in Europe, anyway.

Term Coined

2011-07-28T08:16:00.001-07:00

A very short while ago, a friend of mind posed this question: "What do you call a handjob from a chick with no hands?"

After numerous trials and errors, we came up with this:

http://www.urbandictionary.com/define.php?term=chernobyl+stump+stroke

My Work is Now Cut out for Me

2011-07-09T18:11:00.000-07:00

Okay. So I let myself get sidetracked on the development of my book as a result of having a lot to do at my current job. That's the bad news. The good news is that everything has been "percolating" during this time and I've come up with a really good mental map of how I'm going to guide the reader through all the problems involved in agile database development.

Here it is...

Basically, the idea is as follows.

Goals:
We have the goal of increasing the speed with which value can be delivered by reducing the "bottleneck effect" that generally surrounds database changes. However, we cannot do that at the expense of things we've already gotten good at; namely preserving the knowledge stored in a database and maintaining the availability of its service as experienced by a user via an intermediary application.

Obstacles:
There are risks posed to the things we are already good at by increasing the speed of change. Changing structure, the way we do it now, implies risk to existing knowledge stored in a database. It also introduces the chance that an application coupled to a database might not have had time to adapt to a change in structure by the time a change is rolled out.

There is also an obstacle to agile database development in that whatever infrastructure is required to mitigate the previously mentioned risks will probably not be available for legacy databases.

(From the Other Angle) Axioms:
Databases store knowledge - that is their primary role. To acquire knowledge and make use of it, databases absorb and emit information. Another thing to assume is that people will make mistakes.

Here's the big one: databases are objects. They are objects that store knowledge on behalf of other entities, like applications.

In any environment, where there is risk or instability, test-driven development mitigates those dangers to the point of rendering them almost non-existent. This is especially true in a good object-oriented environment where behaviors can be easily isolated and tested.

Solution:
Good object oriented platforms, and really even mediocre ones, provide the notion of a class. That is: an encapsulated, refactorable unit of design that provides a reliable way to instantiate objects with predictable behavior and easy-to-couple-to interfaces.

Implementation:
We cannot simply take existing mechanisms for defining classes and apply them to databases because the forces around a database are different - they have "inertia" in the form of knowledge that cannot be lost in the course of a design change.

The core of the implementation is to introduce a predictable, highly structured create-or-upgrade path that minimizes errors, protects existing knowledge, and regulates how change is introduced to any given database instance.

The next step is to specify exactly how changes are introduced to a database by test-driving them. This all-but-eliminates the chance that a database will lose knowledge in the course of changing its design.

Once that is accomplished, provide a strong interface for your database to ensure that application developers are warned of breaking changes as soon as they possibly can be. You, yourself, can be warned of these changes by using test-driven development to specify the behavior of the current database.

Finally, there must be a way to handle errors. This is a function of good database development practices - like taking regular backups - and providing a mechanism for rapidly introducing corrections to errors that have already been committed to production. Once you have that system in place, by definition, you will have a process that can be used to enroll legacy databases into your agile database development process.

Where Does the Buck Stop?

2011-07-08T23:18:00.000-07:00

So I just watched another Michael Moore propaganda film and the theme of individual non-accountability continues.

I have a question for anyone who is swayed to believe that homeowners are not responsible for the consequences of their actions or that workers aren't responsible for choosing to work a job where they are underpaid.

If individuals should not be accountable for the consequences of their actions, who should?

The Law of Damocles

2011-07-05T23:31:00.000-07:00

People keep talking about the Law of Demeter. It's a pretty good law - although it seems like a hard one to break in a modern programming environment.

Anyway, I'd like to propose another law based on a classical mythical character: The Law of Damocles: All code exists with a sword poised above its head.

Shit code is better deleted than mutated. Ensure the behaviors are properly specified with tests, delete it, and start writing good code until the tests are all green again.

The Golden Hammer

2011-06-19T21:46:00.001-07:00

I think I've finally turned up something in my search for a compelling reason to use Ruby rather than something else. Here is the first argument in favor of it that includes an actual snippet of code that I have found:

http://wowkhmer.com/2009/01/20/dotnet-coders-should-give-ruby-a-try/

I think people's insistence on Ruby being a worthwhile thing is based on its expressiveness when defining the behavior of an algorithm. Personally, I don't see how the Ruby code in that example is any more expressive than the C# code but that's not the point. For the sake of argument, I will grant that it somehow might be for some people.

It still doesn't matter. People are already able to write and understand very complex algorithms. Making them easier to implement is not a good thing. For one thing, it optimizes the easiest part of what we do. For another, it enables programmers with outdated skills sets by allowing them to do what they are comfortable doing: writing "programs" and wrapping them up in objects.

Defining algorithms is not what good programmers do. What good programmers to is encapsulate variation to such an extent that there is no need to define a complex algorithm. This is very difficult as it requires us to think about things in terms of entities with responsibilities rather than in terms of sequences of steps, some of which are conditionally executed.

So I think that Ruby is a bit of a golden hammer: It's optimized for how it looks rather than how it functions - it focuses on letting people indulge their bad habits rather than providing an incentive to correct their behaviors.

That is... unless there is some way it enables people to define abstractions and encapsulate variation better than other languages. If there is, please send me a link to an example demonstrating.

A compelling reason to learn Ruby, anyone?

2011-06-19T21:37:00.000-07:00

I am presently in search of a clear, concise explanation of what advantage Ruby might provide over, say, C# or Java and rock-hard evidence to back up that(those) claim(s). Any suggestions?

I'm tired of hearing how teachers are underpaid

2011-05-30T16:36:00.000-07:00

Look at this. They get full benefits and are paid around $40k/y to work about a thousand hours a year. That means that, in terms of effort that goes in versus money that goes out, they are paid about like a decent programmer on average. If my experience was at all typical, most of them do a terrible job and don't even try to do a good one. Throw into that that there is a mechanism specifically designed to ensure they don't have to do a good job (tenure), and it's a pretty sweet deal.

I would say being paid comparably to one of the most highly paid professions in our country while not being held to any real standard of quality and, in fact, being explicitly shielded from any such standards puts teachers in the category of "overpaid" rather than "underpaid." If a government wants to cut costs by bringing their pay into alignment with the value they deliver (or at least improving the alignment), then so be it. Don't like it? Find a different job.

Most of the people who should be teaching children probably aren't in it for the money anyway.

Walk away, walk away / I'll be a parade

2011-05-30T16:30:00.001-07:00

"Modus Operandi"

Walk away, walk away / I'll be a parade

2011-05-30T16:29:00.000-07:00

"Modus Operandi"

Why TDD Does Not Replace Compilers

2011-05-21T21:04:00.000-07:00

There is a commonly held belief that the presence of good tests obviates the need for a compiler. It is a myth. It can easily be shown to be false and I will do so in a few paragraphs.

Conceptually
Before demonstrating in concrete terms why a compiler is still necessary. Now, perhaps it is true that the single task of adding a class to a system of classes might not greatly benefit from the presence of a compiler. It also might not be true. Either way, I'm not going to address it because it's not the hard part of what we do.

Where a compiler comes in handy in a way that the simple presence of tests cannot help us is in the process of changing design, not creating it. TDD does not replace design, it augments it by attaching executable specifications to elements thereof.

Compilers tell you when elements of your design are inconsistent. In ways that tests cannot. At least, in ways that tests cannot do without replicating the purpose and behavior of compilers. They do this by allowing you to create positive coupling that can be validated at compile time.

Duplication
To really understand the value of a compiler, you have to understand the nature of duplication. Duplication exists whenever you have to make a single change in multiple places.

Unfortunately, duplication is not actually something we can eliminate altogether. In fact, all the techniques we have been taught for eliminating duplication do not, in fact, eliminate duplication but actually replace uncheckable duplication with coupling - a form of duplication that can be mathematically checked for consistency.

For instance, the signature of a method and the calls to that method are duplication. There are cases when changing the signature also requires the calls to be changed or requires some other change like creating an overload. However, with a strong-typing system such as you often find with a compiler, you have a mechanism to ensure that all calls are at least basically in sync with the methods they are invoking.

Duplication doesn't stop you and rarely even slows you down when you are creating something new. It's when you are changing things that duplication becomes a killer. The reason it is a killer because people seldom find all instances of duplication on their own. I refer you to Shalloway's Law.

Change
Healthy products change a great deal. The more useful and important your software is, the more you are going to need to change its design. There's a small irony there, isn't there? The more your software is used, the more it will change. The more it changes, the more the design will change. The more the design changes, the more you will want to keep instances of necessary duplication in sync with one another.

The key to surviving change in any system of a reasonable size is not to eliminate duplication; that is impossible to do one-hundred percent. Instead, it is to eliminate unnecessary duplication and to comply with Shalloway's Principle (same link as before) in the case of necessary duplication.

Dependencies and Strong Typing
Strong typing, which is typically found in compiled languages, is the only tool we have invented at the time of this writing that combats necessary duplication by linking together all instances of a particular duplication. It's really the strong typing, not the compilation, but at this time the correlation is so strong that you can practically treat them as the same thing, setting aside bastardizations like VB.Net.

Strongly typed languages tend to do this by allowing programmers to create dependencies that are implied by one entity in a piece of software using another. For instance, all calls to a method depend on the definition of that method. You cannot compile things that call a method without basically correct parameters. Likewise, all references to an instance of a type grant the dependent access to its public methods and allow it to pass the referred-to object around as a parameter to suitable methods.

These dependencies can then be checked for an entire compilation unit in a single pass, guaranteeing a basic of potential correctness before even bothering to produce a program that can be tested. Note that, if there were a strongly typed, statically checked, non-compiled language, then the programmer would get the same benefits except that it would happen when the script is loaded rather than when the program is compiled. The difference between those two things would be imperceptible to most, if not all, programmers.

Strong, Weak, Explicit, Implicit, Static, and Dynamic Typing
It is also important to note that I am not arguing for or against most of the traits listed in the title of this subsection. I am arguing in favor of strong typing and against weak typing. I don't really care about implicit typing or explicit typing, nor do I care about static or dynamic typing, except to the extent that they may influence a language's ability to be strongly or weakly typed. Let's go over what these various things mean, in case it is not obvious.

A strongly typed system is one in which types and method calls can be validated prior to the execution of any part of the type system being evaluated. Dependencies are defined in some way (probably by use) that allows the basic compatibility of design elements to be automatically verified with no work required from a programmer beyond defining said design.

A weakly typed system is one that is not strongly typed. That is, one in which a developer has to do extra work to validate the consistency of relationships between entities in a system or one in which it is not automatically done before a design element can be used.

An explicitly typed system would be one in which all types, including abstractions, must be explicitly defined. Java and C# are examples of such a system. If you want to create a polymorphic relationship, you have to create some kind of interface that is implemented by variants of the abstraction.

An implicitly typed system is one in which types, including abstractions, can be inferred by some part of the programming language or environment. A lot of scripting languages do this: you define the interface for an abstraction by how the caller uses implementations. What you may or may not have considered is that C++ also had elements of implicit typing: templates created a de facto interface between the template-ized thing and its dependencies. Note that the dependencies of a C++ template are still checked at compile-time so implicit typing is, by no means, inextricably linked to strong, weak, static, or dynamic typing.

A statically typed system is one in which types cannot be redefined at runtime. C#, C++, and Java are all examples of such a language. You define a type and that's that.

Finally, there are dynamically typed languages. JavaScript would be an example of such a language, where a type could be changed after it has been loaded and even after it has produced an object to be used.

I don't care whether a language has implicit or explicit types. Nor do I care whether it has static or dynamic typing. I may have a slight bias toward the former in each category but I don't consider it a big problem if a language or platform decides to go the other way. It is specifically the strength or weakness of a language's typing system that matters in the context of this blog entry.

Strongly typed systems are preferable to weakly typed ones because they aid in refactoring and extension in ways that cannot easily be done using other tools available to date. They do this by forcing us to reconcile instances of necessary duplication before we even bother testing a code change.

Practically
Hopefully, you are at least intrigued by the theoretical information provided above. However, I recognize that abstract arguments aren't always enough to make one's case so here's a real world example. This is a simple case and, the more complex the case, the more dangerous weakly-typed systems are.

In this example, we have a template method pattern. The pattern is implemented the classical way (through inheritance) even though I seldom do that in real life. No point getting embroiled in another debate before this one is settled. :)

The Setup
In the weakly-typed language we are using (which I'm making up on the spot to avoid getting into a religious war), we have no way to define an abstract method that ensures all inheritors of our base class implement it.

Let's look at the base class now:

class BaseClass
  method DoesSomething(x, y)
    factor = 1
    factor *= ComputeFactorForX(x)
    factor *= ComputeFactorForY(y)

    return factor
  end method
end class

Now, let's consider one inheritor of this class:

class RarelyUsed extends BaseClass
  method ComputeFactorForX(x)
    return 1 + x * x
  end method

  method ComputeFactorForY(y)
    return -1 - (y * y)
  end method
end class

In addition, there are twelve other extensions of BaseClass which are used very frequently. Let's even go as far as to say that we have a strong suite of acceptance tests that validate the value delivered by the software being developed. Even with such a thing, however, it is impossible to test every combination of every object.

Now, as I've stated before. TDD is handy for helping us define the behavior of each of these classes. It may even allow us to prescribe the relationship between them. What it doesn't do automatically is enforce the relationship.

The Twist
Let's imagine that we want to test-drive an extension to the behavior of the base class. That is, we want to change the relationship between BaseClass and its inheritors. TDD allows us to define the behavior as we want and ensure it is done right:

class BaseClass
  method DoesSomething(x, y, z)
    factor = 1
    factor *= ComputeFactorForX(x)
    factor *= ComputeFactorForY(y)
    factor *= ComputeFactorForZ(z)
    return factor
  end method end class
end class

What it doesn't do is make sure that all inheritors of BaseClass conform to the contract it demands. We have to wait until the real application is put together in order to see if we did everything we need to do. Let's say we just plain forgot the type RarelyUsed. Why wouldn't we? It is, after all, rarely used and a member of a family of types that is thirteen-large.

The Punchline
How long do we have to wait for that feedback? Ironically, the best-case scenario is: "Forever." In that scenario, the bogus class is never used and will be deleted the next time someone looks at it. The next-best case scenario would be when your automated acceptance tests run. Even that creates an irritatingly-long delay.

What if it happens during manual testing? The cost of finding and fixing the problem is going to be dozens of times what it would have been if the problem were apparent when making the change originally.

What if it happens in production? The loss of goodwill is possibly irreparable but probably could be smoothed over. However, the cost of finding and fixing a problem with that kind of delay between introduction and discovery would be astronomical, when compared to the cost of finding and fixing it immediately. We're talking hours or days when compared to seconds or minutes.

The Rebuttal
One might argue that one's tests are deficient. For instance, one could have a method that checks for the existence of the required methods on an inheritor of BaseClass. That method could then be called from a test in the test suite for each inheritor.

I'll not try and claim that isn't true. It obviously is. My counter-rebuttal is this:

Yes, you can do that. You can also write your code in assembly and write tests for each method which ensure it is properly formed - that all code paths lead to an exit or to an infinite loop, that it properly puts things in the right registers, etc.

In fact, you can re-write as many parts of a strong-type-system-checker or a compiler. However, doing so either requires you to write a compiler and then use it from a whole bunch of tests or to duplicate your design in the form of tests.

Conclusion
I think I've made some strong arguments in favor of using a strongly-typed programming language over a weak one. You cannot avoid creating duplication so, in addition to keeping to to the minimum amount necessary, you should use automation to enforce as much consistency between duplicates as possible.

I've failed, however, to mention the biggest and simplest argument. I've done this partially because I'm saving it for last. Here it is: there's no cost. It's one-hundred percent free to use a strongly typed language instead of a weakly typed one.

At least, that's how all the proponents of weakly-typed languages seem to make things look. You see. I've spent days trying to get people who don't like type-safety to explain one advantage of not having it. Nobody - not one person I've talked to - has been able to identify a single reason why it even might be better to have a language be weakly typed than it is to have it be strongly-typed.

The closest anyone has come has been something along the lines of "it's more challenging, so I work harder and with more focus." Languages should not provide the challenge. There are plenty of real challenges: getting your tests right, creating a good design, and aligning implementation with business value, to name a few. We don't need made-up challenges coming from languages that represent a big step backward.

So here is my final argument: I've shown that there is an advantage to having a strongly typed system. I submit that until a single, real advantage of weak typing can be identified, that tips the scales in favor of strong typing. If someone can come up with a strongly typed language that is also implicitly typed and/or dynamically typed, then that should be considered to be a competitor to real languages like Java, C#, and Go.

TDD allows you to use a language more effectively than you could without it but cannot make up for fundamental deficiencies in that language. One such deficiency that is presently en vogue is the absence of a strong typing system. You can mitigate that deficiency by writing numerous additional tests but at a number of great costs.

Just because you write good tests doesn't mean you cannot benefit from a compiler or something that fills a similar role and nobody has been able to show me how you could possibly benefit from not having one.

A mile stone in the long road

2011-03-12T10:55:00.000-08:00

DataClass now supports Java. It took a lot longer than I expected but it's done now.

You might be thinking "that's neat but what does it mean that it 'supports Java'?"

Before I answer that, I'll briefly remind you what DataClass does - just in case you stumbled on this entry by accident and don't already know. DataClass is a compiler that takes documents that describe a class of database and produces binaries that know how to build and interact with instances of that class. The point is to give you the same ease of development you would have for any other class of objects; for instance, allowing you to quickly spin up test instances with identical behavior to production instances.

Following is an example of a DataClass source document:

database SomeDB {
  types int as integer;

  version 1.0 : initialized {
    design {
      public table T {
        public column X with DataType = type(int);
      }
    }
    construction { 
      step sql { $[T.Declaration] }
    }
  }

  current version 1.1 : 1.0 {
    design {
      public table T : base.T {
        public column Y with DataType = type(int);
      }
    }
    construction { 
      step sql { ALTER TABLE $[T] ADD $[T.Y.Declaration] }
    }
  }
}

That would create a class called SomeDB that knew about two versions of a database design, knew how to build and/or upgrade databases to either of those versions, and had a body of symbols allowing clients to couple to public aspects of each of SomeDB's various designs (1.0 and 1.1). If stored procedures were involved, there would be a proxy for each version that allowed clients to call these stored procedures as if they were normal methods on a normal object.

Up until build 20.11.1733, DataClass would only produce .NET assemblies that connected to a database through ADO.NET. This most recent build, however, added the ability to produce database proxies and constructors in a java JAR file.

This involved a significant amount of refactoring before it could readily be supported. I had to encapsulate all the variation between Java and C# (not too hard), between the JRE and the CLR (there's a fair amount), and between JDBC and ADO.NET (they work in fundamentally different ways).

The really disappointing thing about this was that I discovered how fundamentally different JDBC and ADO.NET were very late in the game. In ADO.NET, access to schema information and binding by name are both easy and reliable. In JDBC it appears to be expected that you will bind by position - something I thought we left behind two decades ago - because binding by name is possible for certain providers but not guaranteed.

Anyway, that was a problem I could work around pretty easily. DataClass uses the logical position of a parameter or column to infer its physical position. There are, I'm sure, times that this will not suffice. In such cases, developers can use the PhysicalPosition attribute to dictate the binding position of a parameter or a column. That might look something like the following:

public procedure MyProcedure {
  // Inferred: PhysicalPosition = 1
  public parameter F;
  // Inferred: PhysicalPosition = 2
  public parameter G;
  // Explicitly: PhysicalPosition = 0
  public parameter H with PhysicalPosition = 0;
}

Another "gotcha" for Java programmers is the fact that DataClass expects physical positions to be zero-based and adjusts accordingly for the platform. So, even though the first parameter is parameter 1 when binding via JDBC, you must specify it as parameter 0. I guess the point is this: don't take JDBC's implementation details into account as DataClass hides them.

Do not trust CodeMaid

2011-03-04T21:02:00.000-08:00

She steals CodeSilverware.

Seriously, though: CodeMaid appears to randomly delete using statements. I've done a little work to uncover the root cause and identify a fix: it is not ready for production use; uninstall it.

DataClass now available

2011-02-01T17:05:00.000-08:00

It's been a long haul but I think it was well worth it. DataClass is now available for download, trial, or purchase.

Conference Submissions: What to Do with the Rest?

2011-01-17T07:08:00.000-08:00

I was looking through the Agile 2011 submissions and I noticed something. A lot of them are pretty interesting, well thought out ideas. I do not envy the chairs of the various stages their task. They are going to have to make tough decisions about which good talks to include in the conference and who they tell "great idea but there's just no time."

It occurred to me that one mitigation for this might be if conferences like this started soliciting papers from the talks that didn't make it and collected them into a book (or collection of booklets). That way, all the neat ideas that didn't make the cut could still find their way out into the world. If done right, the conference could make a little profit off of coordinating their release.

Agile Database Development: From Requirements to Delivery

2011-01-08T21:14:00.000-08:00

I've received, signed, and returned a contract for my upcoming book, Agile Database Development: From Requirements to Delivery, scheduled for release in 2012. We'll see whether the "From Requirements to Delivery" part of the title survives the book development process. Regardless, the scope of the book will run that gamut.

Something I've noticed - and I really noticed this when I got my first publication contract for Transition Testing: Cornerstone of Database Agility - is that there is nothing like a contract to focus your attention on a project. It's not even the deadline, which I feel was extremely generous on the part of my publisher. It's those words that rattle around in the back of your mind...

This is really happening. The ball is in your court, now.

There is nothing like it to motivate someone. At least, there is nothing like it to motivate me.

Submissions for Agile 2011 Entered

2011-01-01T22:06:00.000-08:00

Hi Everyone,

I've made three entries into the Agile 2011 submission system:

I'd love any review and feedback that anyone may offer.

A Pretty Functional Dynamic Proxy for jni4net

2010-12-29T16:17:00.000-08:00

Wish you could use the dynamic keyword to access java objects created using jni4net? I use this class to do that. Feel free to reproduce it, modify it, or incorporate it into your own products so long as you don't claim that it is "yours" and start suing other people who use it.

It's cut-and-pasted out of my code so there's no guarantee that you won't need to tweak it a little. One might say it's pretty much guaranteed that you will. :)

using net.sf.jni4net;
using System.Dynamic;

public class JavaObjectProxyFactory
{
  public class JavaObjectProxy : DynamicObject
  {
    private readonly java.lang.Object o;
    private readonly java.lang.Class c;

    private JavaObjectProxy(
      java.lang.Object o,
      java.lang.Class c)
    {
      this.o = o;
      this.c = c;
    }

    public static dynamic GetInstance(
      java.lang.Object o,
      java.lang.Class c)
    {
      return new JavaObjectProxy(o, c);
    }

    public override bool TryGetMember(
      GetMemberBinder binder,
      out object result)
    {
      var field = c.getField(binder.Name);

      if (field == null)
      {
        result = null;
        return false;
      }

      result = ConvertToDotNetObject(field.get(o));

      return true;
    }

    public override bool TrySetMember(
      SetMemberBinder binder,
      object value)
    {
      var field = c.getField(binder.Name);

      if (field == null)
      {
        return false;
      }

      field.set(o, ConvertToJavaObject(value));
      return true;
    }

    public override bool TryInvokeMember(
      InvokeMemberBinder binder,
      object[] args,
      out object result)
    {
      var signature = new java.lang.Class[
        binder.CallInfo.ArgumentCount];
      var arguments = new java.lang.Object[
        binder.CallInfo.ArgumentCount];

      for (var i = 0; i < args.Length; ++i)
      {
        java.lang.Object arg = 
          ConvertToJavaObject(args[i]);
        if (arg != null)
        {
          signature[i] = arg.getClass();
          arguments[i] = arg;
        }
      }

      var method = c.getMethod(binder.Name, signature);
      if (method == null)
      {
        result = null;
        return false;
      }

      result = ConvertToDotNetObject(
        method.invoke(o, arguments));

      return true;
    }

    private object ConvertToDotNetObject(
      java.lang.Object o)
    {
      if (o == null)
      {
        return null;
      }

      if (o is java.lang.String)
      {
        var s = (java.lang.String)o;
        return new string(s.toCharArray());
      }

      return GetDynamicProxy(o);
    }

    private java.lang.Object ConvertToJavaObject(
      object p)
    {
      if (p == null)
      {
        return null;
      }

      if (p is string)
      {
        return new java.lang.String((string)p);
      }

      return (java.lang.Object)p;
    }
  }

  public static dynamic GetDynamicProxy(
    java.lang.Object o)
  {
    if (o == null)
    {
      return null;
    }

    return JavaObjectProxy.GetInstance(o, o.getClass());
  }
}

Enjoy.

"Happy Holidays" is what terrorists say. Merry Christmas!

2010-12-17T09:02:00.001-08:00

Even though I'm not a Christian, merry Christmas everyone.

As a gift to the public at large, I've lowered the price of the Goad Testing PDF to free. So get your copy now.

-- Max

United Airlines: An Example of Why Airlines must be Allowed to Fail

2010-08-12T00:44:00.000-07:00

United Airlines just fucked away an entire day of travel for me and managed to not get me anywhere.

I guess it's my fault, really. How silly was it of me to think that eighteen hours was enough time to transport me three hundred miles.

On the other hand, you do have to cut me a little slack because I could have driven to San Francisco from Bend and checked in to my hotel in the time it took United to decide they weren't going to send us where we paid to go.

So here's what happened. I showed up a good two hours early. You know... like you're supposed to. I was told there was going to be a "slight delay" of two hours. "Okay," I said. "That's okay. That's why I am giving myself so much time to get where I need to go."

The idea was to give myself enough time to ensure that the airlines couldn't possibly screw up my very important trip. Long story short: I'm pissing and moaning about the flight being canceled nine hours later (right after I got home).

There was not one person on that plane who would have been less satisfied with a trip to Oakland and a train-ride to SFO than they were with what they got (nothing). Airlines are, by and large, idiocratic entities. Stupid people are allowed to set up elaborate systems that are simultaneously incapable of meeting the fictitious needs initially envisioned and incapable of dealing with the actual needs of real customers.

When a limb is that rotten, the only thing left to do is chew it off. We must allow the airlines to fail.

Quickie Orange Sauce

2010-07-28T21:38:00.001-07:00

Quickie orange sauce:
  1 orange
  1 "new mexico pepper" (whatever the hell that is)
  1/3 cup (ish?) marsala
  1 slice butter
  1 tsp (ish?) cooking oil
  1 tsp (ish?) sugar

Crush orange into a glass
Add the other ingredients
Put in a pan on lowish heat
Stir until it reaches desired thickness (20 - 30 minutes?)
Turn to low heat
Continue to stir occasionally until time to serve

Lowering Cost of Goad Testing

2010-07-26T18:21:00.000-07:00

I've lowered the cost of my long paper: Goad Testing. This booklet shows a weakness in the way we usually do test-driven development along with a discipline we can apply to mitigate it.

I Write Like

2010-07-18T21:05:00.000-07:00

I write like is a pretty neat little tool and surprisingly precise. I haven't read either of the authors it says I write like so I cannot say how accurate it is but I can definitely say it is precise.

Most of the time I paste in a blog entry, it says I'm like this Canadian blogger, eh. The rest of the time, it says I'm like some science-fiction writer/essayist. Even if the comparisons are totally, horribly wrong. Just having metrics capable of consistently mapping one person's writing to one or two other people's writing is worth a golf clap.

Rock on, guys. Rock on.

Software Development and Flow

2010-07-18T12:45:00.000-07:00

In response to Marco Dorantes's post on flow in software development.

Flow is part of it. There are five Lean principles, all of equal importance:

Start with a clear concept of value as a customer would define it
Lay out the series of steps required to create value to define the value stream
Create flow across the value stream
Let the customer pull value
Compete against perfection rather than other organizations

There are tools that allow us to do all five of these. In fact, the tool that Al is promoting quite heavily right now - kanban - enables every single one of those things. So, while I agree that flow is a critical part of the software development process - I don't understand why we are all so focused on the middle part.

It's like saying a ham sandwich with cheese and lettuce is all about cheese. The cheese is necessary and not sufficient.

Moq Sequencing

2010-07-17T14:53:00.000-07:00

Declan Whelan recently responded to my Moq Sequencer post.

Looks pretty good.

Switching web hosts

2010-07-17T14:32:00.000-07:00

My current webhost - ServerIntellect.com - appears to be completely incompetent. I'd put my uptime in the vicinity of seventy-five to eighty percent. Generously. I highly recommend that you do not use them, if you have the ability to avoid it.

I'm going to be switching away in a bit, here.

Support Matrix and Short Term Planning for DataClass

2010-07-06T19:57:00.000-07:00

The next three months are going to be all about expanding DataClass's platform support. I've published the current support matrix. That same page also includes estimates as to when currently-unsupported platforms will become supported.

Anywho... check it out. Also, if you haven't already, check out the way I documented the DataClass syntax and let me know what you think.

RE: Uncle Bob's "Software Calculus"

2010-07-06T12:06:00.000-07:00

...which can be found here:

http://blog.objectmentor.com/articles/2010/07/05/software-calculus-the-missing-abstraction

It don't think the problem is a lack of thought-tools at all. The problem is people won't use the tools we have. Sure, we can keep refining our tool set. We should always do that. I just don't think we should hold our breath for a revolution...

Software development is the revolution.

DataClass Syntax Documentation now Available Online

2010-07-05T14:04:00.000-07:00

I've posted documentation for the syntax of a DataClass source file online (here). It was really not that hard to build the engine that provides documentation in that format and I think it really helps you learn the language. It leads one to the question "Why aren't all languages documented this way?" Surely a human language would be a lot harder but at least programming languages.

Anyway, let me know what you think.

We Reap What We Sew

2010-07-03T09:14:00.000-07:00

...and I have sewn the seeds of a marriage to a tool that no longer provides adequate functionality. All throughout DataClass, I coupled directly to Microsoft's CodeDom framework.

The following were my excuses for not encapsulating this stuff:

What a convenient way to model the code I want to generate.
It's just data.
It's part of the framework, I can trust it.
It will be easy to add support for Java because this is a language-independent format.

Bull...

...shit.

All of it.

Microsoft screwed us all over by getting rid of the J# code provider. The C# code provider ought to work just fine with some small extensions but it is almost impossible to extend. Bottom line, I'm having to write a working code modeling library; albeit one that only meets my needs.

They also gave .net eventing - a bastardized, incomplete, attempt at generically implementing the Observer pattern - a "little overhaul." Translation: the way that you depended on these things working (crappy though it was) is no more. Fortunately, I avoid those like the goddamn plague.

The bottom line, here, is this: If you didn't write it, don't trust it. I'm not saying that Microsoft is likely to deprecate System.Int32 any time soon but you cannot count on them not changing something about how it works. Encapsulate, encapsulate, encapsulate.

...or you will be sorry.

Why Me?

2010-07-01T18:52:00.000-07:00

Has anyone else noticed that the universe or, at the very least, our social and economic system, is set up to reward the stupid, the weak, and the wicked while punishing those who are smart, strong, and virtuous?

Idiots get bailed out from their bad decision making with their credit cards and I labor under the weight of those bailouts. Weaklings choose to live off the government and I struggle under their considerable mass as well. Jackasses intentionally screw over the economy and it's my job to give them a handout too.

Yet, while doing all of that and trying to contribute to society, I can't get a goddamn computer to run right. First, it's hard-drive dies. Then it's power intake. Where is the support system for the people who are generally making this a better place to exist but just happen to actually, literally be down on their luck?

Flattery will Get you All Kinds of Places

2010-06-30T20:43:00.000-07:00

Someone "liked" the DataClass homepage on Facebook. I wish I could figure out who it was. It's very flattering as it was not particularly solicited.

Anywho. Today is the last day before tomorrow and tomorrow is the first day of the DataClass beta. I'm leaving registration open until the 10th. If you don't get a chance to get involved in this beta, there will be another chance in August if you are a Java programmer or work with Java programmers who use a database you maintain.

What Can We Learn about Agility from the Pyramids?

2010-06-28T23:33:00.000-07:00

In response to http://whitewaterprojects.com/2010/06/28/were-pyramids-the-first-iterative-development/.

The author makes a good point. In all likelihood the pyramids were built that way and, again in all likelihood, it did have the effect of a pyramid being ready whenever a pharaoh died. The way these facts are presented tells us something about a lot of things. Not the least interesting of which is the ever-present and ever-intriguing issue of perspective.

On the surface, this story tells us how Agility helped the people building tombs for pharaohs in ancient Egypt. Another layer down, it tells us about how large groups of people organize to become agile. Deeper still is a story of motivations and perspective. Think of this as a practicality sandwich on philosophy bread. The outer layers are important but I'm going to focus on the meat.

How did the ancient Egyptians learn to become Agile when it took us so many decades of lean thinking? It's amazing, really.

In the words of Chazz Michael Michaels, it's mind-bottling. You know, when things are so crazy it gets your thoughts all trapped, like in a bottle?

So while you are sitting there being all astounded by the wisdom of the ancients, let me just add this one little piece of info to the puzzle:

There were no massive cranes back then. There were no steel girders. There was no such thing as temporary scaffolding that could suspend one of those stones for a substantial period of time.

Knowing that, the question has to be asked. How else would they have built a pyramid? What structural, architectural, or engineering tools could they have used to do anything else but build it in shells?

Once you answer those questions, it becomes apparent that they had to be agile. They had no alternative. There were no tools available that would accommodate a big-batch approach in the first place. Being ready to bury a pharaoh who died before his time probably was not even on anybody's mind.

...at least until the first time one died young. Then, maybe, someone said "Hey! It's really handy we've been building these tombs this way, now we can just drop him off in the center and start working on the next guy's pyramid!"

There is no evidence that the ancient Egyptians' agility was a consequence of their wisdom or foresight. Quite the opposite, agility was mandated by the context in which the supposedly agile people did their work. There is a nugget of wisdom in that fact.

I think it is this: People are not naturally agile. Don't try to control the person, instead control the context in which they work. Make agility easier than the alternative and the people will do the hard part of the transition for you.

Frustrated by SlideShare

2010-06-26T12:14:00.000-07:00

SlideShare has some cool features and I really like the idea. However, I do find its user experience maddening. Not that I am the king of user experience or anything... the Hexagon Software website is evidence enough of that.

Still. I'm one guy with a day job. SlideShare appears to be a company that does this as a reason to exist. Mostly the problems I have come from two things:

Delays
Unclear directives

Delays

I get that it takes time to do something like process a document into a SlideCast. What I don't get is why there is no indication to me that I should be waiting. Frequently, SlideShare will tell me something is "done" but it does not appear to actually be done, yet. There is no way for me to determine whether something went wrong or everything is fine except to wait.

Unclear Directives

Generally speaking, buttons don't do what I think they should do. This is especially true of file uploads. Am I uploading a video? A slide deck? A document? Why, when I try to upload a video, does the Open dialog not show videos but, when I try to upload a slide deck, I have to sift through a bunch of videos?

What Can We Learn?

In reality, these are all just examples of poor feedback. A simple note saying "Your new document is in the final stages of processing. Please be patient." Would save a lot of pain and suffering. A few extra developer hours on their upload technology would save decades in user time over the course of the next year.

Why & how DataClass can facilitate Agile database development

2010-06-25T21:43:00.000-07:00

I've released another video on the topic of DataClass. This time I go over what the problems related to database development are and how DataClass helps you resolve them.

DataClass 1.0 Beta Program Impending

2010-06-23T23:04:00.000-07:00

Well, I'm excited to say that the beta program has reached critical mass in terms of registrants so we are definitely on for July.

Make sure you sign up here if you are interested.

I'm really excited about the opportunity to build a new product using what I know about business, product, and software development today. DataClass is something that is a big deal for me because it is the result of nearly half a decade of accumulated knowledge. Everything I learnt we shouldn't do with DataConstructor, I made sure isn't done by DataClass. All the most important things I wished I could have are in DataClass.

Moreover, it represents a whole new way of thinking and of working with databases. The vision I've been pushing in my courses and in my writings is now facilitated by a single logical document compiled by a single tool.

I look forward to getting real feedback and releasing the initial version of DataClass and I hope you do, too.

DataClass Case Study #1: Solving the Duplication Problem

2010-06-19T17:23:00.000-07:00

I've posted a short (12 minute) video on SlideShare that shows how you can use DataClass to eliminate duplication between the documents you used to define your database and your .net database client. I intend to hit Java in the near future.

Here is a link to the video.

Stay tuned and be sure to sign up for the beta if you want to be a part of it.

DataClass 1.0 Beta Program Open

2010-06-19T11:15:00.000-07:00

The DataClass 1.0 Beta program is now open. DataClass is the next generation of DataConstructor technology. It is smaller, faster, and does a heck of a lot more.

If you are interested, the sign-up form can be found below. You will get a beta license to the product to be used over the course of the month of July. You will then get a survey to fill out in August. When you fill out the survey, you will get a complementary 1-seat license to DataClass as a thank you.

Click here to go to the beta sign-up page.

Two Customers

2010-06-07T08:06:00.000-07:00

In response to http://whitewaterprojects.com/2010/06/04/who-is-your-cutomer/.

I respectfully disagree with the concept of a "technical customer" in addition to a "business customer." It may just be a semantics thing but I think it's important to keep the customer's place special.

The customer is the customer. For the team closest to the customer, that is not difficult to see. For teams "behind" the teams on the "surface" of an organization, it gets a little cloudier. I think it makes more sense to think of the intervening teams between yours and the customer as downstream work-cells. As such, they have the power to specify what an upstream work-cell builds in the moment.

The mental difference, however, is that they are not considered customers when your organization is working to optimize the whole.

Now, if there are two kinds of customer, I would say that there is a business customer and a process customer. That is, you can spend time delivering value to your actual customers, or you can spend time increasing your organizations capacity or lowering its cost.

The process customer is going to be interested in any project that eliminates waste. This might be traditional process projects like training in the latest methodology. This might be the acquisition of a tool. This might be something we don't think of as process but that plays heavily into it, like refactoring or covering legacy code it tests.

The business customer just wants what it wants.

2010-05-28T16:29:00.000-07:00

Oblivion for One
By Max Guernsey, III

Stop all the clocks?
Why bother?

This is the end...

...of life.
...of love.
...of joy.
...of pain.
...of experience.

At least, for one. At 2:30 pm, today, one of our cats, Seelie, died.

For those of us left here, we go on; some more affected than others. Yet, that's not really the point... is it? Mourning is an inherently selfish thing. We lament our loss; our pain; our experience; but those things all pale in comparison to what Seelie has lost: existence itself.

She is no more. To her, there is no more "to be." There is no more her for there to be no "to be" to. Nothing. No experience. No love. No joy or hate. The world does not exist.

So I say "Stop all the clocks? No need. Prevent the dog from barking with a juicy bone? No call."

For Seelie, the clocks have stopped and the dogs have stopped barking. From her perspective, those things all happened and more: The entire universe, including herself, ceased to exist the moment she died.

Who will be next?

DataClass is almost here!

2010-05-21T21:36:00.000-07:00

The new version of DataConstructor, DataClass, is almost ready for prime-time. I've got all of the critical v1.0 features ready for release and all I have left is the packaging and tutorials. I'm looking for beta testers so, if you are interested, let me know.

Each beta tester earns one Agile team a license to use v1.x of DataClass.

Quitting stack overflow

2010-05-21T17:27:00.000-07:00

I tried being a member of the stackoverflow community. At the end of the day, it appears to be no different from facebook... just another waste of time mindlessly drifting wherever the winds of mob mentality take it that day. All investment, no return.

I'm done and you should seriously consider the following question, if you are a user: do you really get any value from it or is it just another addiction to a meaningless point system.

DataClass nearing completion

2010-05-11T08:37:00.000-07:00

As many of you know, I'm working on the next generation of DataConstructor technology, DataClass. I am personally very excited about this new product - it takes database building, design, and testing to the next level. Here are some of the benefits that DataClass has (with red asterisks next to the benefits DataConstructor gave you):

It is a compiled language.

The only things not compiled are the SQL and DDL scripts themselves.

It enables designs with zero duplication.

No duplicated strings even between database scripts and .NET code.

It facilitates transition testing knowledge.*

DataClass still enables you to build a database from any historical version to any future version.*

It alleviates the need for most transition testing design.

For certain database platforms, basic design structures will be validated implicitly.

It does not require a license at runtime.

The compiler is the licensed component, not its output.
The developer is licensed rather than the application.

It allows you to define a complete class of database.

Transition logic.
Public, private, and protected design elements are all defined in one document.
Version info.
All are compiled into a single .NET class.
Public aspects are made public.

Mr. Graffin: My Uneaten Greens Are a Feast for Some, I Say

2010-04-13T22:19:00.000-07:00

I just went two days without a substantive meal. That's right: Fatty go hungry. After two freaking days, I prepared for myself a meal I would never have previously considered eating and, guess what: It tasted great.

It takes me back to when I was a boy scout. We went on this one hike that felt like forever. At the end of the day, we made ourselves "hobo dinners." Right up until now, that dining experience is still my fondest. When I try to recreate it, I never succeed because I am not famished.

Here we are, the fattest, most abundantly fed nation in the known history of the world, and we can't get a decent meal. The constant availability of relatively cheap, delicious food has driven our expectations to the point where we are difficult to satisfy and impossible to wow.

So, when I listen to the Bad Religion song "Quality or Quantity" - which I often do - and I hear Mr. Graffin lament the woes of the poor folk who live on "just seventy cents a day," I am forced to wonder "Do they really have it so bad?"

My point is this:
Have no sympathy for people who are living off of "less than the cost of a cup of coffee" a day; they are eating better than we do.

Book Titles

2010-04-12T21:49:00.000-07:00

As some of you know, I am in the process of writing a book having to do with Agile database development. This book contains a lot of the ideas I cover in my course (shameless plug).

Since a lot of Agility ports straight across to database development, I'm largely not dealing with those issues. I'm trying to come up with a name that conveys "this book helps you overcome the technical impediments to Agile database design." Following are my ideas. Any votes or suggestions would be welcome:

Agile Database Design: Just-Right, Just-in-Time
Agile Database Development: A Technical Perspective
Just-in-Time Database Design: And All It Entails
The Test-Driven Database: Building Solid, Flexible Data Stores
The JIT Database: How To

Basically, I'd love to hear any suggestions you have.

Very Simple Sequencer for Moq...

2010-04-04T16:43:00.000-07:00

Following is a very simple tool for testing Moq...


public class MoqSequence
{
  private int expectedSteps;
  private int actualSteps;

  private MoqSequence() { }

  internal static MoqSequence GetInstance()
  {
    return new MoqSequence();
  }

  private class SequenceException : Exception
  {
    private SequenceException(string message)
      : base(message)
    {
    }

    internal static SequenceException GetInstance(
      int expectedStep, int actualStep)
    {
      return GetInstance(
        "Step " + expectedStep + " executed when step "
        + actualStep + " should have been.");
    }

    internal static SequenceException GetInstance(
      string message)
    {
      return new SequenceException(message);
    }
  }

  public void InSequence<T>(ISetup<T> iSetup)
    where T : class
  {
    var expectedStep = expectedSteps++;

    iSetup.Callback(
      () =>
      {
        if (actualSteps != expectedStep)
        {
          throw SequenceException.GetInstance(
            expectedStep, actualSteps);
        }

        actualSteps++;
      });
  }

  public void Verify()
  {
    if (expectedSteps != actualSteps)
    {
      throw SequenceException.GetInstance(
        "Expected " + expectedSteps + 
        " steps but only got " + actualSteps +
        " steps");
    }
  }
}

Here is an example of how to use it:


[Test]
public void ExecutesStepsInCorrectOrder()
{
  var sequence = MoqSequence.GetInstance();

  sequence.InSequence(transactionMock.Setup(
    t => t.Lock()));
  sequence.InSequence(transactionMock.Setup(
    t => t.TransferAssetsIntoEscrow(escrowMock.Object)));
  sequence.InSequence(transactionMock.Setup(
    t => t.SchedulePayouts(escrowMock.Object)));
  sequence.InSequence(escrowMock.Setup(
    e => e.ReconcilePayoutsWithHoldings()));
  sequence.InSequence(escrowMock.Setup(
    e => e.ExecutePayouts()));
  sequence.InSequence(transactionMock.Setup(
    t => t.Complete()));

  transactionCoordinator
    .RunTransaction(transactionMock.Object);

  sequence.Verify();
}

Do You Have a Jesus Problem? Alcohol is the answer.

2010-03-27T16:00:00.000-07:00

Do you frequently get high on Jesus or Moses when you are alone? Are you afraid to talk to your friends about where you went last Sunday? Do you hide bibles around the house so your spouse can't find them?

These are all signs of religion abuse. Religion abuse is a very serious condition that affects nearly two out of every three Americans. If you don't suffer from religion abuse, look to your left, then to your right. Both of those people probably do.

The affects of religious abuse last a lifetime. Long term religion abuse can affect your personality, making your presence less pleasant or even unbearable to others. People who are high on religion are often extremely suggestible and will do practically anything to "score" a shot at "heaven." Worse still: people who abuse religion often pass their condition on to their children.

Even though it's completely ridiculous, these facts show that religion is no laughing matter.

But... if you suffer from this condition, I have some good news: there is a way out. By giving yourself over to Alcohol, you can blind yourself to the evils of the world. Through Its powers, you will become blissfully unaware of your suffering and will no longer feel the need to justify it by contriving fictitious entities who watch over you and have a "good reason" for putting you through a living hell.

And the wages of delusion is death of joy, but in Alcohol there is joy everlasting.

Remember: you don't have to live like this. You can think for yourself and you can find a way to cope with the cold, barren, empty void that is our existence without depending on imaginary figures from ancient fairy tales. In Alcohol, there is redemption. Turn yourself over to Alcohol and start living your life.

The New Threat: Global Sideways-ing

2010-03-20T15:04:00.000-07:00

People just don't get it. Ever since several groups started trying to warn us about man-made global warming, there's been a small cadre of crackpots who've said crazy things like "Wait a minute! Isn't the Earth just going through its normal cycle of warming and cooling?" or "Hey! It seems like we shouldn't be worried about global warming when the Earth is near the bottom of it's ordinary temperature range."

Oh sure, the scientific and media community has been able to throw together some numbers and change their language against statements like the latter by changing "global warming" to "climate change." ...but the threat those people pose still remains. How exactly do you deal with it when someone has a modicum of knowledge about the Earth's climate history in a larger context, one that generally does not include man? How do you handle pesky lunatics who want to point out that tens of thousands of years ago could not have been the last ice age because it was part of this ice age and, in fact, we are in what is known as an "interglacial period?"

You can try and show how insane they are for pointing at things like "evidence" and "historical data." I'm sure that's what these fine, upstanding people would say is the right course of action.

However, I would like to point out that those of us who do believe in global warming; those of us who keep the faith in spite of the evidence - because that's what it's about, after all: keeping the faith - have been focusing on the wrong thing...

You see, this is a complex problem full of complex numbers and, as everybody knows, complex numbers have two components: the real part and the imaginary part. Our problem is that we've been trying to convince people that man-made global climate change exists using real numbers and the real numbers have been very uncooperative.

What we need to start doing is helping people comprehend the threat posed by the imaginary numbers. After all, the true threat lies in the imaginary component of the evidence we have collected, rather than the real part. Let's look at a concrete example.

Let's say that last year, the global average temperature went up by 0.1°F - don't bother to fact-check, I made that up as a hypothetical. Someone could argue we have absolutely no evidence whatsoever that, when exiting an ice age, the temperature should not go up as fast as it did.

What these people don't understand is the imaginary impact of that change and the very real threat it poses. Let's take a closer look:

While, in our hypothetical example, the real component of climate change was only 0.1°F, the imaginary component could be 10i√(°F). The good news is that we have no way of measuring this number so there is no way for those "that's not what the evidence suggests" fruitcakes to show that they are completely fabricated. The bad news is that same attribute makes it so that those same nut jobs can say "because we cannot measure it, it won't have any measurable impact on our lives."

This can be resolved with the simple remedy of applying "what if;" the tool we used to generate a buzz and get people worried about ~~global warming~~ climate change in the first place. All we have to say is "What if some event were to occur that caused the imaginary portion of our climate change to be squared? Where would be be then?"

If our actual global average temperature were, say 67°F + 10i√(°F), and the imaginary portion were to be squared, the real part of our global average temperature would drop 100°F - a global catastrophe. Likewise, if the temperature started out as 67°F - 10i√(°F), the temperature would jump 100°F - killing pretty much everything everywhere.

This proves, I think, that the real threat is not global warming, weirding, or climate change but Global Sidways-ing, man-made changes to the imaginary portion of our global average temperature that could lead to very disastrous consequences if mathematics were to fundamentally change in a way that caused those imaginary numbers to become real.

Living without Dryer Sheets

2010-03-20T10:51:00.000-07:00

Now that I live in Bend, one of my biggest problems is static electricity. Every time that I reach for my computer at work, I get shocked; sometimes hard enough that the affected finger goes a little numb for a few minutes.

Another problem I have is that I am lazy. Horribly, horribly lazy... at least when it comes to mundane things. Ask my wife, she'll confirm: I'm the laziest person there is. Think you're the laziest? Wrong. It's me.

So, long story short: I don't have dryer sheets because I am too lazy to walk across the street and buy them. So my static electricity problem is worse than ever before.

Problem: My pants carry too high a static charge.

Solution: Wrap them around the faucet while I'm brushing my teeth.

Faucets are pretty well grounded things. Wrapping your clothes around them for a few minutes will drain them of most of their static charge.

So, if you are lazy and don't want to go get dryer sheets - or maybe your one of those new-age enviro-douches who lives in constant fear of the dryer-sheet-ocolypse... whatever the case, if you don't want to use dryer sheets use the faucet to de-staticify your clothes before you wear them. You have my personal guarantee that it will work.^*

* Personal guarantees made by Max Guernsey, III are backed by nothing. Void where prohibited. Void where permitted.

Your Last Chance to Sign up for My Database Agility Course is Approaching!

2010-03-15T20:04:00.000-07:00

Tomorrow, the Early Bird Special prices for the March-April Database Agility Online Training will expire. Although I will probably start another one no later than July, my schedule is pretty hectic so don't assume that I'll be starting one in May or June. I might but I cannot make any promises.

For those of you who don't know what this course is about: it tackles the critical problems that make Agile software development difficult in the database domain.

Automation and Value Streams

2010-03-14T19:13:00.000-07:00

Recently, I release a book called "Goad Testing: Deepening our Understanding of Automated Tests." While the general purpose of that particular writing is to help people find ways to keep their bed of tests as healthy as the tests help them keep their production code, it also hits on something that I believe and I talk about implicitly but never call out as a topic of its own...

Automation of any kind - programs written for customers, machines that build cars, video games, and, yes, tests too - are really instruments of process improvement. In every single case they have no less than one of the following effects on some value stream:

They provide access to information which enables the completion of a step
They reduce the amount of time a step takes
They improve the quality of the outcome produced by a step

...and really, these all resolve down to a single impact:

Every piece of useful software reduces the amount of time required to complete some step in a value stream.

Whether or not the amount of time required without software made the step in question infeasible or caused the quality of its output to suffer is irrelevant, it's all a function of not being about to make a decision, come to a realization, trigger an action, store your findings, etc. quickly. There is nothing that software can do but we people cannot, given enough time. Even the fact that software runs the same way every time it is executed in the same context translates into an impact on the time it takes to get something done by minimizing the potential for rework.

It all comes down to time and process, which is what Lean told us in the first place. The customer for a test just happens to be the development team that will use the test to avoid releasing crappy software to their customers.

Why does this matter? ...because people bandy about all these different explanations of what tests "really are..."

A test isn't really a test... it's a specification
A test isn't really a test... it's process control
A test isn't really a test... it's a performance metric

Tests have the side effect of eliminating the need for a lot of those things but, at the end of the day, a test is a piece of software that reduces the cycle time of a development team by eliminating delays between the introduction of a defect and its discovery.

A.K.A.: a "test."

Some Guy's Crazy, Cheesy Dream

2010-03-04T19:00:00.000-08:00

This guy's trying to take $250k from Dorritos so that he can fight cancer and stuff.

Check out his video here.

Branching with Design

2010-03-01T22:18:00.000-08:00

Code. Code never changes.

The end of the world occurred pretty much as we predicted. Too much duplication. Not enough manpower to go around. The details are trivial and pointless. The reasons, as always, purely human ones.

(adapted from the beginning of the last real Fallout game)

I hate branches. I hate them... and why shouldn't I? Here is the promise of a branch...

We're going to defer integration for a long time so that it will cost more when we do it but don't worry, until the branch is merged, we're going to essentially maintain two copies of the same code base. Make that three. Make that four. Make that... ah fuck it.

Recently, a pretty decent argument was made in favor of branching...

We have to change X. Whenever we change X, everyone on the team is broken for months.

Naturally, the first response is "Well, it shouldn't be that way." To which the person with whom I was having the debate replied...

I know but it is.

Check...

We're trying to fix it but that's the way things are right now.

...aaaaaaand mate.

The team understood that it was a huge problem and wanted desperately to fix it but didn't have the resources to do all of the necessary refactoring before they had to change X. Because of the size of the system, its complexity, and the level of encapsulation around X, there were going to be breaks; no "if"s, "and"s, or "but"s about it.

So what to do, then? The answer is, as I'm sure you've guessed now, to branch with design. What, precisely, does that mean? The steps can be summarized pretty simply as follows:

Find the places where X, is used and its behavior needs to change.
Create a Facade that exposes just the functionality needed by those touch-points.
Promote the Facade to an abstraction with its only variation being the classic usages of X.
Make the old behavior the default variation of your Facade abstraction.
Create another variation into which the new behavior is placed; provide QA with a place to "turn on" the new behavior.

The alternate behavior can be a Proxy to X, an alternate implementation... it can even be incomplete or not work - it's not being used in the normal "production" code path. Yet, your "branch" is continuously integrated.

Without even touching your continuous integration configuration code, your "branch" will be built with the rest of the code. If a test fails against it, your build goes red. If you forget a semicolon, your build goes red. You will receive continuous feedback as though you didn't branch... because you didn't. Yet you will be able to insulate people working on other things from pain caused by your changes as if you did.

Now, I'm not claiming this as my own. It would have to be crazy to do so as it is basically nothing more than a narration of how the Facade pattern plays out when you pursue it aggressively. My point is not "Hey! Look at this neat thing I invented," because I didn't invent it.

Instead, my point is that you can always do this and it always works. I'm sure that, somewhere out in the world, someone has a good reason why they absolutely have to branch. Disregarding such one-in-a-million scenarios, you should always branch with design rather than with source control. It's safer, cleaner, and lower cost.

Upcoming Database Agility Online Training

2010-02-28T08:59:00.000-08:00

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!)

2010-02-27T16:24:00.000-08:00

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

2010-02-25T20:25:00.000-08:00

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?

2010-02-24T21:50:00.000-08:00

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?

2010-02-21T13:46:00.000-08:00

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

2010-02-19T23:48:00.000-08:00

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.

Why does my code get screwed up?

2006-02-21T20:53:00.000-08:00

Why does blogger.com screw up my code? Does anyone out there know a good way to post code?

I've yet to find a good way to post an attachment.

The Barrier Method

2006-02-20T00:58:00.000-08:00

They say it's the only safe way... use a barrier method every time.

Seriously, though. I was pleased to see that .Net 2.0 contained an implementation of Semaphore. It contains a lot of cool stuff. Something it doesn't have, though, is a barrier. Barriers are a synchronization tool that can be used to ensure no thread starts working until the desired number of threads are ready.

A good real life analogy for a barrier is the starter in a race. The starter makes sure that all of the runners (threads) are at their marks. When all of the contestants are ready, the starter fires his fake pistol and they're off. That's what the barrier does. It's not the most commonly used synchronization tool - I use it mostly in tests - but it can come in handy.

Below, I've implemented a barrier as a wait handle. I commented it a little but, frankly, I'm tired. It should be pretty clear how it works.

Google blogging screws up one's code, so I've moved the example to a seperate text file.

WebPart Skins & User Controls

2006-02-19T12:41:00.000-08:00

Today, we're developing a web part. This web part has the requirement that administrators be able to edit the user interface through the web UI. Since more than instance may be deployed to a single web site and one web site can span more than one host, we cannot simply provide an editor for a file.

What we really need is the ability to treat one of our web part's properties as a user control. Of course, user controls are useless if they can't have scripts or databinding in them, so we cannot simply use TemplateControl.ParseControl; we have to use LoadControl. Now we see our problem: LoadControl requires a file but we want to persist our control as a property.

The solution ends up being pretty simple: We store the body of our skin as a property of our web part with freshness data. In the solution provided here, our freshness data is a Guid and the body of our skin is the text portion of a user control (we are foregoing code-behind, for now). Every time an instance of our web part is rendered, it tries to load its skin from a cache directory (which is also specified via property) using the Guid as its name. If the file does not exist, we create it.

The result is, effectively, every time an administrator saves a change to a web part, a new use control will be created on every host. Since the user control is loaded from a file, it will get the advantage of ASP.NET's caching & compilation infrastructure; meaning it can have custom code and data-bindings in it.

Unfortunately, Google Blogs screws up source code. You can download an example here.

A nightly job can clean up old items by simply deleting all the files in the cache folder: the ones worth saving will get regenerated the next time they are needed anyway.

"Why?" you ask, or maybe, "Why not just use files?" I cannot answer that. I mean: I know the answer; I just can't give it to you right now. There are some out there who know why already. To anyone who asks "why" the only legal answer I can give you is "you'll see."

Skin me. Skin me, my friend.

2006-02-15T21:09:00.000-08:00

Skin me again!

Okay, today I'm going to give you a little example of skinning. This is a super-simple case. Here, we have a controller class called "SquareIt." SquareIt lives in an assembly named "SkinExample.UI" and inherits from System.Web.UI.Control. There is also an interface ("ISquareItSkin") that serves as the contract between the SquareIt class and its skins.

For simplicity's sake we are just dealing with skinning. We are not separating any business logic into separate classes.

Let the code speak for itself.

Let's talk about skinning

2006-02-15T01:11:00.000-08:00

No, not the "it puts the lotion in the basket" kind: the "my UI and business are loosely coupled" kind. In this post we are going to discuss a good way to break the user interface out of your system: Skinning. When you make your application "skinnable," you allow users to load new looks-and-feels at run-time. There is a Skin Pattern out there. Unfortunately, there is no definitive authority on what, exactly, the Skin Pattern is. There don't really seem to be any good authorities on what any pattern is, for that matter. I am going to talk about a way of implementing Skinning, not the way.

Skinning is little more than a fancy name wrapped around the Model-View-Controller pattern. Why that's not called the "Model-Controller-View" pattern is lost on me. Really quickly: Let's not get true skinning confused with ASP.NET Themse or Skins, which solve the problems that css should have. If you are one of those people who is in to service-oriented architecture, think of the skin as just another service: the "interface with foreign actor" service. If you are into MVC, think of a skin as a loadable view with a few extra restrictions. If you are someone who doesn't need fancy-pants terminology wrappped around everything you do then, well, good for you... we could probably be friends.

Consider the leftward class system. There are a number of business objects which represent the "Model." If you are an SOA guy, then they are your various data and business intelligence services. There is a controller that coordinates between the business objects and the skin. Finally, there are skins which compose the "View." For SOA people, the skin is just another service that allows foreign actors to communicate with a system.

There are slight differences between making an application "skinnable" and using the MVC pattern. For one, in the MVC pattern, the view is allowed to access the model. In the implementation of skinning proposed here (and in any instantiation of the Skin Pattern worth its salt, really), the Skin (the View) is not allowed to talk with the business objects (the Model). Also, while skins cannot provide new functionality, they are able to hide existing functionality. Additionally, there is a difference of intent. Most often, I have seen MVC used to create modularity between the presentation, the business intelligence, and the data; the ultimate goal being maintainability. Skinning, on the other hand, generally takes advantage of modularity to allow run-time selection and/or customization of the UI; the ultimate goal being flexibility.

In the diagram above, you should see an ISkin interface. This interface should serve as a contract between the controller and the skin. The contract defines three means of interaction:

Messages from the Controller to the Skin
Messages from the Skin to the Controller
Shared data

Messages from the Controller should be passed to the skin via method calls. Messages from the skin should be posted via an event. Shared data should be referenced by properties. Once you have defined the contract between your controller and its skin, you may then implement the skin and controller in whatever order and manner you choose. The end result is that you have a modular system in which new user interfaces can be deployed independantly of the application itself.

A code example of how this might be implemented will be posted in the near future.

PolyLoginView

2006-02-05T22:16:00.000-08:00

This is another variant of LoginView. This one is for building a role-based dashboard. It instantiates the template for each applicable RoleGroup. A RoleGroup is considered applicable when all a user is in all of its roles.
Of course, since Google Blogs screws up my code, I have to put it here.

ScopedLoginView

2006-02-05T18:09:00.000-08:00

Okay, here is a LoginView that is not bound to the default provider. Of course, I would like to be able to just post it to the web, bug Google Blogs does not support that, so I have to put it here, instead.

Is Java on its way out?

2006-02-05T00:01:00.000-08:00

Of course not. I hate stupid questions like that. "Is .Net dying?" is just as idiotic.

People who ask questions like that are good arguments for eugenics. There. I said it. If you call into question the short-term survivability of a platform as vibrant as either .Net or Java, you should be sterilized. As should all of your offspring.

...possibly anyone who didn't slap you when you initially asked the question.

Okay. That's out of my system. Pending a disclaimer, let's ask some real questions.

DISCLAIMER: I am not an authority on Microsoft's motives. I am not an authority on anything, for that matter.

Question #1: A common pattern, in today's world, is to program to an interface and use an abstract factory, service locator, etc. to obtain instances thereof. How come most of the .Net framework does not use this pattern?

Answer #1: You won't like the answer.

Question #2: No, seriously, tell me!

Answer #2: Because you make them cry. People, generally, don't understand things. For instance: beyond the basics, I don't know how a car or a lung works. The world is big and scary. It is filled with monsters, wars, tragic deaths, and scary spiders. These and a myriad other things all drive the average person - including the average programmer - to simply "tune out." Having to explicitly use an abstract factory or other "servicey-locatory-type-thingy" is an extra step that half the people just won't comprehend and the other half will question the validity of. Using new, on the other hand is comfortable; It's easy to read and understand.

Fortunately for everyone, those tricksy hobbitses at Microsoft figured out a way to build a "servicey-locatory-type-thingy" directly into the .Net platform: binding redirection. Through this artifice Microsoft can update a .Net framework assembly without disrupting dependent assemblies. That's right: Because of binding redirection, you can sit on your couch, drink your pepsi cola all evening, leave the reality TV shows running while you sleep, then drive your SUV to work and keep using new without having to worry if Microsoft is going to update an assembly on you.

The bottom line is this: They did implement a dependency inversion mechanism it's just too transparent for most people to see and they did it that way because they don't trust you. I don't trust you either but that's probably not your fault: I know the coffee machine lies but it's words are like honey... I just get all mixed up.

Question #3: Should I just use binding redirection?

Answer #3: If you have to ask, the answer is probably "no." There are reasons to use it and reasons not to use it. Let's go over them together as two friends holding hands:

Good points:

You can apply it to applications you have already deployed
It allows for intuitive construction of objects using new
It requires no maintenance

Bad point:

There is really only one bad point. Reliance on binding redirection as one's primary mechanism for dependency inversion hides certain design problems until after the fact. If you have to conform to a service location mechanism, you are more likely to think about where boundaries between services and consumers might be. Likewise: you are more likely to use interfaces to address a class hierarchy than actual implementations.

The System.IO namespace is a good example of the downfall of reliance on binding redirection. All streams must derive from System.IO.Stream, which is monolithic and does not capture the essence of "streamness." Instead, because .Net's linear inheritence is so limiting, it attempts to provide hooks for all features that a stream might offer. If you need a concrete example, take CanTimeout, ReadTimeout, and WriteTimeout. In a proper, interface-driven, class system, one might break these out into a seperate interface (one that implemented IStream); it is likely that CanTimeout would retire altogether.

Again, this is not a failing of binding redirection, it is a failing of the class-system designer. Binding redirection is just an accessory.

I tend not to use binding redirection and, when I'm helping an organization set its infrastructure up, I recommend against it. A custom solution is easy to implement (more on that later... I'm tired), easy to maintain, and begs certain questions that historically people do not ask.

Why, god? Why?

2006-02-04T21:42:00.000-08:00

All I ever wanted from you was... ten... million... dollors!

Seriously. I'm smacking my head up against a wall looking for a way to tell my LoginView which RoleProvider to use.

Well, not really. It is annoying, though. I guess we'll just have to write one that is complete.